All right, I welcome to my talk, simplifying,
keep it, new tools for easier VM management.
Let me introduce myself first, so I'm Felix Matoshek.
It's not on the microphone.
It's only for camera.
It's only for camera here, and there are a lot of people,
so we need to actually work with this one.
All right, so yeah, I'm Felix Matoshek,
Senior Software Engineer Dreadhap,
and I'm working on a Cupert, including its command line, utility,
and Ansible bindings, and also on other parts of Cupert.
So let's have a look at today's agenda.
First, I want to give you a short introduction to Cupert.
Then we'll have a look at Cupert CLI and enhancements to it,
in the latest development cycle.
Then I want to show you how to use an automated VM life cycle
with Ansible, and after that I'll try to give you a demo
of everything, and lastly I'll show you some next steps
for the topics we've discussed.
So first, what is Cupert?
It's a way to run and manage VMs on Cupert netty,
so Cupert might be an opportunity for companies wanting to get to know Cupert netty,
that already half VMs are interested in container workloads,
and all you can do with traditional VMs,
you can do with Cupert VMs as well,
but Cupert brings VMs into the container world,
so you can make use of Kubernetes features such as services
and others as well.
So Cupert netty has to offer something on top of traditional VMs,
and not only that, but it also allows you to combine
virtualized and containerized workloads.
So for example, you could run like an existing
virtualized application on your VM,
and combine it with a new containerized microservice,
and follow this, Cupert extends Kubernetes with several VM-related
custom resource definitions, and provides agents,
and controllers to actually provide the business logic required
to run the virtual machines,
and under the hood it's using LibWirt,
and QMO to run one QMO process per container,
which contains the VM.
And here, just like for a quick look,
how Cupert, which machine CereD, would look like,
I'm not going into the details,
but like only for rough context,
this is like a minimal VM,
that would be a bootable,
and later we'll move in our space and inspect,
so I'll show this here quickly.
Next I wanted to give you a reminder about a topic,
I've given a talk about in the past,
which is since the types and preferences,
and this topic will become a bit more important later in this talk.
And so these are custom resource definitions,
combining resource sizing or runtime preferences.
Runtime preferences are like settings,
your virtualized OS would expect from the virtual machine,
like shaping the hardware of a virtual machine essentially.
And one of each of the ins and certain preferences
can be referenced by a virtual machine,
and later they will be applied to the actual
virtual machine instance, that's then derived from the virtual machine.
And by now, Cupert ships pretty fine,
instance types and preferences,
so we ship preferences for common access like,
Ubuntu, Rell, CenderS, etc.
So you can start right off the box and run your VMs on Cupert.
And yeah, keep in mind just a different approach to creating VMs.
So the full custom, customizability is still there,
if you use the full definition of a virtual machine.
But in most cases, this makes life easier.
So let's have a look at Cupert CLI, which is a call of virtual CTO.
It's a tool with several features.
So first, it allows you to control the lifecycle of virtual machines.
We think like starting, stopping, restarting your virtual machine.
But it also allows you to create VMs,
instance types and preferences.
And for that, it provides a fixed set of flex on the CLI
to adjust the parameters of the objects you can create with it.
So in case of a VM, for example, you could specify the name,
the boot volume that's going to be used,
the instance type of preference, the VM should use.
And all of that is then output it into a manifest,
which I think it's quite nice because it allows for quite nice one-liners,
creating objects directly on your cluster if you'd like to.
But if you choose to, you could also save this manifest into a file.
You can then customize it further or choose to deploy your VM
with a GitHub approach or something like that.
And also it provides other quality of life features.
I would say most not worth the is the remote access to SSH SAP and VINC.
What's nice about it is that you only need the configuration file
for your cluster control plan.
So you'd only need access to your cluster API.
And then you can essentially use port forwarding to access these services
on your virtual machine.
So you can then SSH into your virtual machine or copy files to it.
Or access the screen of the virtual machine.
And there were several enhancements to which to deal
in the 1.4 development cycle of Cupert.
So what's it here? Create VM, gain several new features.
The first feature would be the generation of cloud init configurations.
Before that, it was only possible to specify a base64 encoded string
on the command line, which contained the cloud init configuration,
which is not very user-friendly, I'd say, but was there.
The second feature is the injection of credentials through the access
to credentials API we have in Cupert.
Third feature is support for Sysper volumes.
So you could now bootstrap your Windows guests on Cupert as well.
And then there were many more cleanups and fixes applied to it to deal.
So it's a most noteworthy, is the unified volume import.
And for that, the UX for importing volume city command line was streamlined.
So it's easier now to import volumes for example,
let's say, from HTTP or registry.
And now I want to have a closer look at the first feature here,
the generation of cloud init configurations.
And then what it does is it allows you to log in and use a VM right after creating it.
There's no more need to compose basic configurations of cloud init yourself.
And I have an example here.
So this would be the what city create VM command.
And I'll give it the user flag because I want my VM to have a user called my user.
And I wanted to have an SSH key, which is in this case,
right from file in your home directory.
So feature of the shell, but I think it's quite nice because it allows you to read from a file.
And then below, there's an excerpt of the which machine was created.
And under its volumes, volume containing the generated cloud init configuration was added.
And in this cloud init configuration, the SSH key is statically injected.
So I abbreviated here the key but you get the point.
And my look simple, but in my mind, it's what say it's very, it's amazing.
Sorry, makes life amazingly easy because especially in definite environments where you need to create a lot of VMs and throw them away again.
You now can create them with a one liner and at least for my work makes life a lot easier.
And you could try this yourself, but keep in mind there's no boot volume in this case.
If you wanted to try it, like keep in mind, you need to add a boot volume for it to actually work.
And then I have the second feature here, which is the injection of credentials.
So on the slide before, we statically injected an SSH public key.
And this time now we're injecting it dynamically, which means we're using the access credentials API to read a public key or a password or multiple passwords.
From from a secret.
And I have an example command again.
Again, the user flag for my user.
And then this time I'm using the access credit flag, which would take multiple parameters.
In this case, I'm only using only a single one, which is the source parameter.
It tells the tool to use the secret called my keys to source the keys from.
And below it, and there's another example for which a machine that was created.
And we see that in its access credentials, an SSH public key was added.
And it's using the QMO guest agent method to propagate the public keys into the virtual machine.
So the guest agent is responsible for writing the authorized keys file of a user.
And this works dynamically.
So it sources the keys from a secret called my keys in this case.
And if we change the secret while the VM is running, the guest agent will update the keys in the running which machine.
And what's great about this feature is that it allows you to store your secrets separately from your machine definition.
So yeah, it's best practice to keep your secrets somewhere safe, not in your machine definitions.
And now we've seen a way to deal, which works well at a small to medium scale.
But let's see how we can manage VMs at a larger scale.
For that, I wanted to show you how you can automate the VM life cycle with Ansible.
I hope you all know Ansible.
It's a ubiquitous tool to automate a key tasks.
And Cupid now provides it's own Ansible collection, which is called Cupid Core.
And this collection provides lean bindings to support the most common tasks for Cupid VMs.
It also allows you to reuse existing tooling in the process.
So it makes Wachim machines, Cupid Wachim machines available to Ansible as any other host for Ansible.
And this allows you to use reuse existing content like roles or playbooks if you have them.
So yeah, also because Cupid VMs are now regular host to Ansible.
You can use it to manage data activities at scale as you would with your other host as well.
So you can now easily apply a configuration change or update your fleet of VMs or stuff like that.
And you can get this from Ansible Galaxy today.
It's also shipped by default in the Ansible distribution.
I think we're starting with version 9 or something.
Let's have a closer look at the contents of the collections.
So first we have some modules.
First the Cupid VM module, which allows you to create update or delete VMs.
It's kept lean intentionally, but it still allows you to change most of the parameters found on a VM.
So we've seen earlier the definition of the VM.
There's a template back inside and you could still choose to modify it with the VM module if you'd like to.
And also it allows you to wait for changes to be propagated.
So let's say you're starting stopping the VM or changing a configuration per meter.
Then in a regular Ansible Playbook, you would expect that if your task is finished that the changes are applied.
But for VMs, changes are not like they're not applied instantly.
It takes some time.
So by default it's running asynchronously.
But you can choose to wait for the change to be propagated.
So the next step in your Playbook, then we can build on the top of your or a previous change.
Then we have the Cupid VM and VMI info modules.
That also allows you to look up VMs on a cluster.
If you don't know which VMs are on a cluster.
It supports filters like label or feed selector.
So you could also filter by namespaces.
And if you already know which VM you would like to get more information about that's possible too.
And these modules are read only.
So you cannot change anything about it or about your VM with them.
So it's safe to run them against running with your machine.
You cannot like harm your application if there's something running inside that machine.
And the next is my favorite part of the collection, which is the inventory plugin.
This inventory plugin allows you to populate your inventory dynamically from data on the live cluster.
So this runs against the cluster.
It discovers the which machines on the cluster.
And then it also allows Ansible to connect to these machines by discovering SSH connectivity to the VM essentially.
So it tries to find a suitable Ansible host, an Ansible port combination.
And there's a certain pretty sense to that.
So you could specify a network name on your virtual machine.
And then it would like it would try to find the interface of that virtual machine.
You specify it.
And sorry, I meant the IP address of that interface.
If not, then it tries to find services exposing the SSH of your virtual machine.
So if you have a load balancer, a node port service, exposing the SSH of the virtual machine,
it would try to connect to them.
And if not, then it falls back to the first interface on your virtual machine, which usually is the pot network.
So if you run Ansible in the same cluster as your virtual machine, or at least in the same pot network,
then it would still be able to connect to those VMs.
And the plugin is designed to handle like large scale environments.
So you can do all the usual stuff you can do with other inventory plugins as well.
So you can group and filter by a cluster name namespaces, labels,
it supports key groups, compose variables, all the stuff.
And of course, you can also use it like with tools like AWS.
So that makes it really useful in these cases.
Okay, so yeah, I wanted to give you a demo about all of this now.
I wanted to make this demo focused on folks running Kubernetes and liking to give,
keep it a try.
And the aim is to show you like a complete scenario of all I've shown you before.
So we want to include the CLI and Ansible.
And I'll show you also how you can get a running cluster and connect Ansible to it.
And I want to try it live.
If not, then we can fall back to the slides.
So just let me move this over.
So first, let's create a, sorry, a Mr. Step.
I want to show you how to create a cluster.
But I'll show you later.
So first, I have a running cluster already.
I have the OTTL.
And I want to create an instance type and a preference with that.
So first, let's run OTTL create instance type.
We pass it a name and amount of CPUs and amount of memory.
And already exists because I tried before, so excuse me.
But we can have a look at the manifest which would have been created.
So we see it has two BCPUs and two gigabytes of memory as we specified.
And then I want to create a preference.
I already did this before.
So I'll just show you how the manifest looks like.
So I specified that it should have a CPU to pull it off course.
So the default would have been sockets.
But I want to assign my BCPUs to course.
And I've seen that the preferred CPU to pull it is course.
And next I'll create, I'll create the VM with Ansible.
And for that, I have a playbook, which I'm running in the background.
Well, I'll explain to you what it does.
So this uses the keyboard VM module to create a VM on the cluster.
Then it applies to instance type and preference.
We just created.
I have a secondary network support on my cluster.
So I can connect to the VM on a layer two level.
So it attaches a secondary network to that VM.
And lastly it injects an SSH key statically so we can connect to it.
And this is a bit up to the Wi-Fi now.
So maybe it works, maybe it doesn't get it.
So we have a running VM on the cluster now.
And next step would be to run the inventory against the cluster.
And for that, I have an inventory configuration, which is quite small.
It's using the inventory plugin provided by the keyboard core collection.
We wanted to look at the default namespace.
And we tell it to use a network name called Bridge Network.
That's the secondary network I just added to that which you machine.
And if I run Ansible inventory with this configuration and tell it to list inventory,
essentially this is running against the live cluster.
And that's the virtual machine, which is running on the cluster.
So first scroll up here, there's the virtual machine.
So test VM.
And we see that there's also Ansible host, which is the IP address of the virtual machine.
And the secondary network.
And now I'll run a playbook against this machine deploying HTTPT.
And we see we want to accept that.
So this is deploying HTTPT on the virtual machine now.
So we have like an example application.
And what's important here is that we need to point Ansible playbook at the inventory.
We need to give it a user and the private key we just unchecked it as it can connect.
And this is now up to the Wi-Fi again.
It works.
If not, we can go back to the slides for a second.
Because I told you I would show you how you can create a cluster and actually connect to it.
So Ansible to it.
So I forgot about that part.
For this, we're using the actually the test environment of the corporate core collection.
So this would be step free in the slide here.
That's using Docker or potman to spin up a cluster.
And thanks to potman or Docker, we easily get support for secondary network.
You can run all of this yourself.
I uploaded the slides to the first page and should all work.
So you could just copy and paste it and it should hopefully work.
If not, you can contact me.
I'm happy to help.
So please try it yourself.
And I just see that the playbook was applied successfully to the VM.
So I want to show you actually the other works.
If my VM is working, then yeah, it is.
So the IP address of the which machine was this here.
And if we go there, we see actually the HTTPT is running on the which machine.
So it worked.
The Wi-Fi was nice to me.
So now the slides are completely broken, but that's fine.
Can show you the slides anymore, but.
Anyway, I just want to conclude what we've did in the demo.
So we successfully created a cluster with the test setup of Cupid Core.
We connected.
Ansible to it with the inventory plugin and we created a VM on that cluster.
And we successfully deployed an application on that cluster.
And lastly, I have some next steps, which I'd like to show you.
Okay, some few more next steps.
So in the future, we wanted to make work to deal more easy to extend because right now there's still some some boilerplate code involved in it.
We need to address some usability issues in Cupid Core.
So there's still some issues if you run it against the cluster and the VM is modified in the in the same moment.
And there can be identity issues with Cupid Core.
And lastly, we want to carefully at the features to the collection.
One big feature would be support for fact caching.
And lastly, we need your feedback.
We need to know from you what you would like to see in the collection in the future.
And that's it.
So, thank you.
Any questions?
Yeah?
Cupid.
I will also talk about the public cloud there.
I would like to add a draw and go over.
If I understood correctly, the question is, is Cupid supported on public cloud's AWS?
Actually, you can just deploy it on a regular Kubernetes cluster.
You can run this cluster yourself or you can use a managed cluster.
This works.
For it to work optimal, you would need bare metal notes.
But you can choose to run nested virtualization, but it's like it's dangerous territory.
It can work, but it can cause issues.
But in general, it works.
You can deploy it on a cluster on a public cloud.
Can you do both of the public vendors like Microsoft and Amazon?
If the question was, is it supported by vendors of the clouds?
If you run it yourself, then it's not supported.
It's your own application, but there are offerings based on Cupid.
So you can find them some clouds.
Any more questions?
And that's it.
Thanks.