And in that file, I'm scrolling down to this highlighted line right here.
Looks like I'm using just a plain, out‑of‑the box,
generic configuration file because what you'll find,
and again we'll get more into the details the next lesson.
But you can create a config file with all of the options disabled by default.
That'll give you a good opportunity to explore,
and that's what's happening here.
My inventory statement is commented out.
So yeah, I've got some work to do to get this system up and running.
So it's basically Ansible installed, and that's literally about it.
Let me try the same thing.
Let me try this time a code, and I'm going to do etc/ansible/hosts.
We'll take a look at my host's inventory file.
Now, what just happened is from within WSL, I called the VS Code executable.
And I'm now having a live remote connection.
Well, if it doesn't fail.
I don't need GitHub Copilot here, so that's fine.
I think this worked.
What I want to show you here, this is just an extra tip that's super useful,
especially for learning and development,
is to make sure that on your host Windows machine,
the one that has the WSL installed where your Ansible controller is going to be.
In VS Code, there's some extensions that I need you to be aware of.
Let me take a look here.
First of all,
not all of them are available here because I'm in the WSL environment.
But in my host computer, I have the official Ansible VS Code plugin.
Because we'll be dealing with Python eventually.
I've got the official Microsoft Python and Pylance extensions installed as well.
And very importantly,
Microsoft has an official WSL extension that makes
it a snap to do what I just did.
From within WSL, now we can get on our host computer the goodness of VS Code.
And I can open a folder inside that WSL instance,
and I'm going to open up etc/ansible.
That's true because I want to see the inventory file that I have.
And I just want to see, yeah, it looks like I do have an ansible.cfg.
I mean, I'm just exploring this newly installed system with you.
So we're kind of looking at it together.
This looks cleaner than the output we had before.
Let me zoom in the fonts.
Yeah, so there's our ansible.cfg.
And you saw earlier that right now my system is pulling from the
home directory rather than the global directory.
Frankly, I want to have my config file here in the global location,
etc/ansible, so it's available across the entire server.
So that's one of two config files that's absolutely crucial right
out of the gate getting started with Ansible.
The other is your inventory.
Normally it's called hosts, but it doesn't have to be.
I would suggest that you do keep that naming standard.
And you can format it in YAML or INI format.
I personally like INI.
That's what I'm using here.
And what we've got in my file is I've created a host group called
control that right now consists of a single machine.
It's my Windows Server domain controller.
And one neat thing you can do is that you can change this name.
You can make this foo if you want to.
So I know that some organizations have strict VM and server
names that don't make a lot of sense, so you can alias those.
And then just throw in the Ansible host variable and supply
the DNS name or the IP of that machine.
So that's just a little trick.
So you may have a different section in your inventory for different roles,
web servers, API logic servers, database servers.
And then you can customize by attaching variables as you can see here.
And the INI structure is pretty straightforward.
If we don't want to clutter up our host with all these
embedded variables at each host, we can round them up and do something like this,
control:vars, and now we've got a bunch of variables that we can set.
These are all ones that are required for Kerberos that
we'll discuss more next time around.