How to get a GitOps cluster in 20 minutes with Civo - part 3

Welcome to the third and last part of this series on how to get a GitOps cluster in 20 minutes with Civo. The first article was about preparing for the magic to happen, and creating a production-ready management cluster with multi-cluster support. In the second one, we explored a little of the new cluster you created, and all its tools so you don’t navigate in unknown water. In this blog post, I’ll guide you toward some ways you can customize your new cluster, going from GitOps, to using our beautiful interface.

Customizing your new platform

kubefirst did its job; it created a new management cluster, just for you. It is now yours, and it’s time for you to take the ownership of it, and make it yours.

GitOps

There are multiple ways to customize your new cluster, and they all start, and end with your gitops repository (more information about GitOps in our documentation). As we respect the GitOps principles, this new repository is now your source of truth. Everything in your new ecosystem is under some sort of code form within Git.

The users having access to the different tools installed for you are in Terraform files within the terraform folder. Same goes for the infrastructure needed to create the clusters. All applications, and configurations are in different YAML files, structured and organized in an easy and understandable way within the registry folder. If you want to manually customize your new environments, this is the place to be.

GitOps Catalog

We have to admit that playing directly within the repository is not for everyone. This is why we created the GitOps catalog to help you install new applications in, what I call, the proper way to do ClickOps. In the catalog tab, you will see a list of predefined applications that aren’t installed by default at creation, as we try to limit the number of tools we install to make the cluster as lean as possible, and not taking too many decisions for you. Once you click on the “Install” button of one of those, it will do the work for you of adding the proper YAML files in the gitops repository.

The, even better, thing about the GitOps catalog is that it is open source, which means that you can add the application you think are missing from it. If you don’t want to add it, or are not sure how, feel free to create an issue to request the wanted application, and we’ll add it for you.

Manage your workload clusters

An important part of having this new management cluster is to be able to create new workload clusters as needed. You do not need to restrict yourself to the three defaults virtual ones we created by default to give you a preview of the platform capabilities right from the start. The good news is that all new workload clusters will have access to the tools installed in the management physical one, like HashiCorp Vault, and Argo CD.

Before I show you how to create the workload clusters, if you want to know more about the capabilities of the 2.3.X new interface, the addition of workload clusters or understand better the difference between physical and virtual ones, I highly recommend that you watch the recording of the 2.3.0 release livestream.

Physical Clusters

You may be worrying about workload clusters as you’ve only seen virtual ones once you logged in to your new console management interface. As my homebody Yoda would say “Worry, you should not” as you can also create physical ones. To do so, click on the “Add workload cluster” button. It will bring a side popup where you’ll need to enter the information about the new workload physical cluster you want to create. You will need to provide the cluster name, region, instance size, and number of nodes in addition to selecting in which environment this cluster will be created.

Once you press the “Create cluster” button, the cluster creation will start, and you will be presented with a link to see the process within Argo CD. A second link, not available right away, is pointing directly to the cluster configuration in your gitops repository, as everything you do in the UI is reflected in Git.

If you click on the top link, a new tab will open in the browser to your Argo CD instance, directly within the workload clusters view. Note that if you were logged out of Argo CD, you will see the login screen, and will be able to log back using HashiCorp Vault as the SSO provider.

If you want to visit the testing cluster folder from the gitops repository, click on the second link as soon as it’s available. You’ll be able to see what is added by default in terms of the configurations files and applications. We keep the resources to a minimum, so it’s up to you to add the application you want to run inside this newly created cluster.

Lastly, you will now see your new cluster provisioning from our very sexy user interface. The provision process will take some time as we first need to create the public cloud, and after that, Argo CD will sync and install whatever needs to be installed based on the gitops repository content.

Virtual Clusters

We are all used to physical clusters, but there is a new sheriff in town: vclusters, or virtual clusters. They act like real physical clusters, but they live within the management physical one. They are perfect for development or testing purposes so you don’t have to create new physical clusters. If this is a new concept for you, I propose you take the time to watch the embedded livestream recording below, in which we introduce the concept to our community. You could also read the vcluster documentation.

To create one, the process is exactly the same as physical ones, except you won’t have to specify the region, instance size, and number of nodes.

Once you press “Create cluster”, you will be shown the same information window, and you will also be able to see a new item in the cluster management list view, or a new node in the graph one.

Have fun!

Congratulations, you learned how to customize your platform by using the UI, and knowing that you can always do everything you need manually using the gitops repository. You created new workload clusters, and played a little more with Argo CD, and GitHub. From now on, you can do whatever you please with your new production-ready management and workload clusters.

Before I forget, you remember cluster zero? We could have torn it down right after we validated that everything was working well with our new Civo cluster, so here comes nothing, run kubefirst launch down to make it disappear, and free some Docker resources. Do not worry about the message saying your platform was destroyed: it’s not about your Civo cluster.

With that said, if you were only testing the platform, or played a bit too much with it, and would love a blank slate, we have a guide to help you deprovision your Civo cluster. This is a thing I love about kubefirst: in addition to helping us create production-ready clusters, it’s a perfect playground to test things, and learn more about amazing cloud native tools. You screwed something up? No problem, destroy, and start again; it’s only a couple of minutes!

This ends the last article of this three-part series. I hope that these blog posts were useful to help you create, understand, and customize a new management cluster with workload clusters and the tools you need to be successful, all that in minutes instead of weeks. As always, we are welcoming constructive feedback, features ideas, and overall comment on your experience with our open-source platform. The best place to do that, or ask for help if you encounter any issues, is our Slack community, where you can join more than 300 other cloud native enthusiasts!