So before we jump into the demo, Windows‑Related Ansible Modules.
There's quite a few that Red Hat maintains.
And again, this is just the slightest to just give you some additional assurance.
If you're leery about moving to Ansible in a Windows environment, win_ ervice.
Look in the docs for that to learn how it works, managing windows services.
You've got package management, installation management.
Win command is great because you can just send an ad hoc PowerShell or
shell command and have it run on the target host.
So win command is a great Swiss army knife module.
Win‑user is going to handle local user management.
Win_gather_facts.
Facts is the Ansible term for all of its knowledge for managed hosts.
You know, with simple network management protocol,
the idea of traps and and attributes and so on there,
just metadata about the system.
Well, in Ansible, collected data are referred to as facts,
and win_gather_facts allows you to do inventory reporting.
And then lastly, win_ template.
This is a special case that you'll understand more by the end of this course.
But this is great for creating config files.
Like let's say you've got a JSON config file for an
app or an IIS or Apache config file,
it allows you to dynamically build config files,
again using that Jinja2 templating language that we'll learn more about later.
In the meantime, let's get into that hands‑on demo, shall we?
All right, well, let's configure Ansible.
We are back on my host computer that has a WSL2 Ubuntu virtual machine,
and let's get into Ansible configuration.
So let's do ansible ‑‑version.
And there, I'm noting the config file location.
And the global path would be /etc/ansible/ansible.cfg.
But ultimately, you've got your config file.
Now, couple things I want to show you actually.
Speaking of config files, there is ansible‑config view.
This is a good way to actually visualize the active
settings in your config file.
The Ansible config file also uses that INI format that some of you IT
old‑timers like I am remember in the Windows 3.1 days,
for example.
But we can see that I've customized, well,
you may not see, that I've customized my config file.
The default section is the most important because this is going
to give Ansible the intelligence it needs.
For example, where is the default root path for Ansible config files?
Where is the inventory?
So these are top‑level defaults for the server.
And the syntax, again, is very simple.
It's just the defaults, and then we've got these comments as just a hash sign.
Or old school, you can do the semicolon.
And there are just various reserved keywords and values,
and we can read about those in the Ansible docs at any time.
All right, so let me get out of here, and let's go to VS Code.
I have a WSL2 connection in VS Code on my hardware host to the controller.
And we're looking at my home directory, which,
again, is where I choose to keep my ansible.cfg.