Tutorials

1. Introduction Last week I did some work on the blog’s design, and I was a bit under the water, so I ended up forfeiting working on this blog post. Today I will start by doing a quick recap on how to get the lab deployed by using my GitHub files. It assumes that you have the Proxmox automated install .iso per Part 1. Then I will proceed to explain the CLI procedures for Corosync and Ceph. This part is way shorter and much more straightforward than what we’ve been doing before. I was aiming to get you to experience the process of scripting and figuring out what to do. Now we’re more practical. I don’t know if at any point I will script this. It’s possible. Maybe partially. You have a freedom to make mistakes and redeploy the whole lab in 3 minutes, use it. ...

1. Introduction 1.1 Foreword Over the last 2 weeks since I have started to write this series, I was asked a few times “what about” Ansible, Terraform and other automation tools. The easy answer is: they are besides the point of what I’m trying to achieve right now. When I learned to build a VMware cluster, I learned to build the virtualization platform first, and to understand the network topology and the whys. I think that good teaching builds toward something. This tutorial series is a lot about learning a builder’s mindset and learning how to put some things together. It’s not about a quick recipe for a ready-to-go thing. If I was aiming at just that, I could easily go to a “here’s the GitHub repo, here are the requirements and some basic instructions and off you go”. Or even “here’s the repo, go to your chatbot and figure it out”. Instead, I want the reader to see the struggles and feel the needs for certain tools. I’m also adding a lot of personal touch, like the way I’m doing the ~/libvirt directory. I like the idea of taking the chance to teach a new trick or two, or go into territory that most DevOps Engineers or SREs don’t go to. If you think about it, in this series I’m teaching how to build a virtualization cluster. I’m also excited to iterate on my network diagram designs, on the cluster design itself and for people to maybe see it and feel stoked to get into “learning the craft” through repetition and persistence. ...

1. Introduction Now, we will be deploying an enterprise-grade lab. Therefore we need to think about how we do things in production: we can’t be clicking around and hoping for the best. This quickly compounds. We also need things to scale, to be idempotent (magic word for “always works the same”) and self-healing. As I see this series going right now, we will be iterating the design of our lab a little bit as we go, since there is always room for improving and learning. That being said, I have done some changes to Part 1 to keep things consistent with this new post, add some stuff and fix minor errors. You should check it out. ...

1. Introduction 1.1. Lab Design I have some cool experience deploying and configuring a Proxmox cluster with High Availability and fully redundant Ceph in production. I thought it’d be cool to share my insights. Since I have been meaning to redeploy my lab on my laptop to test some things, I thought this is a good time. To start, this post will be about setting up the lab environment and install one Proxmox instance. I’m going to write a few other tutorials as I go. You are free to use the content here as you see fit. I would appreciate being credited, but that’s not a requirement. ...

Introduction Systemd service units are files which define a service, and when/how it’s started. They will normally refer to a program or script to be executed. There are 3 fundamental sections on a service file: [Unit] is where the description resides, as well as the conditions to initialize the service, such as requirements and dependencies. [Service] is where the parameters which determine how to run the service reside. [Install] is how to enable the unit. It’s optional, but normally necessary. ...