Not sure if you like squashed commits, but I like small git commits based around a single change, but if you accept the request, I guess you can squash it then.
The first commit adds a devcontainer. I like devcontainers. They're really useful for VS code. It sets up the entire environment you would need to run the plays. It doesn't interfere with anyone who doesn't want to use it. I added it because I needed ansible and didn't want to install anything on my base system.
I added an rke2 group as a supergroup of the servers and agents. Makes for easier easier when you're targeting all groups. Not strictly necessary -- probably more of a personal preference on my part. It could definitely be left out and the targeting kept as is.
The ansible config makes it so you don't have to specify the inventory on the CLI or accept host keys for what are probably test lab servers.
I moved some of the group_vars into role defaults and vars. I could understand wanting all these specified in this "global" vars section so it's easy to know what you can change, but most of the time these things won't be changed, and I think it's more understandable to put the things you NEED to put in there and then go over the "and you could also change these if you wanted". The URL I think is a good change though -- no one will ever need to change that -- it belongs in a vars section in the role.
Fixing directory permissions I think is obvious. You had 644 for a directory. You surely meant 755.
I added an argument specs file for the kube-vip manifest. All the roles would be better with this, but this was as far as I got, and it was the first one with a required value. If someone forgets to put a vip argument in all.yaml, the role will error out. I should have commented out that vip parameter too. It's pretty unlikely someone using this other than you will use that specific IP. I have more thoughts about the vars though. Maybe for another PR.
Finally I combined the first two roles into one play. This feels more natural to me. You're making multiple connections to the same hosts by using two plays which is slower. Maybe you feel it's easier to read or have another reason I've overlooked. Again, this one might be personal preference.
I don't think you should gather facts when they're not used for anything though. It's such a slow task. If you aren't using them, set it to false. Actually, even if you are using them, set it to false, and run the setup module in your role to gather the facts you need. That's more nuanced, but as a rule of thumb.
Not sure if you like squashed commits, but I like small git commits based around a single change, but if you accept the request, I guess you can squash it then.
The first commit adds a devcontainer. I like devcontainers. They're really useful for VS code. It sets up the entire environment you would need to run the plays. It doesn't interfere with anyone who doesn't want to use it. I added it because I needed ansible and didn't want to install anything on my base system.
I added an rke2 group as a supergroup of the servers and agents. Makes for easier easier when you're targeting all groups. Not strictly necessary -- probably more of a personal preference on my part. It could definitely be left out and the targeting kept as is.
The ansible config makes it so you don't have to specify the inventory on the CLI or accept host keys for what are probably test lab servers.
I moved some of the group_vars into role defaults and vars. I could understand wanting all these specified in this "global" vars section so it's easy to know what you can change, but most of the time these things won't be changed, and I think it's more understandable to put the things you NEED to put in there and then go over the "and you could also change these if you wanted". The URL I think is a good change though -- no one will ever need to change that -- it belongs in a vars section in the role.
Fixing directory permissions I think is obvious. You had 644 for a directory. You surely meant 755.
I added an argument specs file for the kube-vip manifest. All the roles would be better with this, but this was as far as I got, and it was the first one with a required value. If someone forgets to put a vip argument in all.yaml, the role will error out. I should have commented out that vip parameter too. It's pretty unlikely someone using this other than you will use that specific IP. I have more thoughts about the vars though. Maybe for another PR.
Finally I combined the first two roles into one play. This feels more natural to me. You're making multiple connections to the same hosts by using two plays which is slower. Maybe you feel it's easier to read or have another reason I've overlooked. Again, this one might be personal preference.
I don't think you should gather facts when they're not used for anything though. It's such a slow task. If you aren't using them, set it to false. Actually, even if you are using them, set it to false, and run the setup module in your role to gather the facts you need. That's more nuanced, but as a rule of thumb.
Love your videos. You do great work.