One of the best outcomes of Ansible's move towards content collections is it spreads the thousands of modules in Ansible's "core" repository into many more independent repositories. This means movement on issues and modules that had long been delayed (often due to the sheer volume of issues and pull requests in the repo) can progress more rapidly.
Obviously, not all modules will get the same love and appreciation as others—that's the way open source works: more popular things flourish, as others may languish a bit—but one bright example of the positive impact has been the Kubernetes collection's ability to incorporate some long-awaited Helm modules.
Thanks especially to the work of LucasBoisserie, three new Helm modules were merged into the Kubernetes collection:
Ansible has long had a helm module, but it was fairly broken for a long time, only worked with older versions of Helm, and was slated for deprecation in Ansible 2.14. That version of the module will still work the same in the regular community distribution of Ansible, as it's now been moved to the community.general collection.
But if you want to use these new modules to automate your Helm deployments using the Kubernetes container orchestration system, you can do it with the community.kubernetes collection.
What is Helm?
Helm says it is "the best way to find, share, and use software built for Kubernetes."
There are currently dozens of ways to deploy software into Kubernetes and OpenShift clusters (you can even do it using Ansible natively with the k8s module), but Helm is often the easiest onramp to Kubernetes deployments, especially when you're starting out on your Kubernetes journey.
The way Helm works is that people maintain "charts," which are templates describing "how to deploy application XYZ" into Kubernetes. Charts can have "values" that override the default settings for a deployment's chart.
There are thousands of charts on Helm Hub you can use to install popular software. If your software is not included, you can build and host your own Helm chart repositories.
What is Minecraft?
For a certain generation (or their parents), this question doesn't need an answer: Minecraft is the best-selling video game of all time, and it appeals to an extremely wide audience because there are so many different ways you can play it.
I remember spending an hour here or there during my post-college years tending to a farm that I built in my little virtual Minecraft world. Minecraft can now run on almost any computing device with a screen, and networked play has become very popular. To support this, the Minecraft team maintains a Minecraft server application you can run to play networked games with your friends.
Where does Ansible fit in?
I like to think of Ansible as the "glue" that holds automation together. I previously wrote about how Ansible is useful in a cloud-native environment, so I won't rehash why I use Ansible to manage my Kubernetes infrastructure.
In this article, I'll show you how to write a short Ansible playbook to manage the setup of Helm's Minecraft chart in a cluster. In a real-world infrastructure, this playbook would be one small part of a set of plays that:
- Build or configure a Kubernetes cluster
- Deploy monitoring tools into the cluster
- Deploy applications into the cluster
Before you can write the playbook, you have to install Ansible's official Kubernetes collection. You can do this either by requiring it in a requirements.yml file (which could be used by Ansible Tower to install the collection automatically) or by manually installing it:
ansible-galaxy collection install community.kubernetes
Once you have the collection, it's time to write the playbook. To make it easy for you to view the code or download the file, I've posted my minecraft.yml playbook as a Gist on GitHub.
The playbook uses many of the Kubernetes collection's modules:
k8smodule creates a namespace,
helm_repositorymodule adds the
itzgHelm repository, which contains the Minecraft Helm chart.
helmmodule deploys the chart and creates the Minecraft server instance.
k8s_infomodule retrieves the NodePort where Minecraft is running so that you can connect to it from Minecraft.
The playbook assumes you have a running Kubernetes or OpenShift cluster and a kubeconfig file that points to that cluster already. If not, create a Minikube cluster on your workstation:
- Make sure you have Minikube installed.
minikube start, and wait for the cluster to be created.
After a few minutes, the Minecraft server will generate a spawn area and be ready for connections! The playbook should provide the Minecraft NodePort at the end of its output (e.g., Minecraft NodePort: 32393).
Get the IP address of your Minikube cluster with
minikube ip, add the NodePort to it (in my case, 192.168.64.19:32393), then open up Minecraft and connect to it:
- Click Multiplayer.
- Click Direct Connection.
- Enter the server address (the Minikube IP and Minecraft NodePort).
- Click Join Server.
And voila! You should be able to play around in the little virtual Minecraft world that's running on your very own Kubernetes cluster.
View the server logs with:
kubectl logs -f -n minecraft -l app=minecraft-minecraft;
In the logs, you can see that I was successful in finding many ways to die inside my little Minecraft world!
Take a step beyond
There are dozens of ways to deploy applications like a Minecraft server into a Kubernetes cluster. Luckily for us, Ansible already supports most of those options through its Kubernetes collection! And if you want to take a step beyond simple deployments and chart updates, you can use Ansible to build a Kubernetes operator with the Operator SDK—in fact, someone already made a community operator built with Ansible that runs a Minecraft server!
I was inspired to write this after using Ansible to manage a seven-node Kubernetes cluster built with Raspberry Pis. You can learn more about that in the Turing Pi Cluster GitHub repository.
If you want to learn more about Ansible, make sure to register for AnsibleFest, a virtual experience on October 13-14.