Now looking at this Ansible config file,
you might be thinking, well, Tim did this file just materialize out of thin air?
No, no.
Could I create a blank ansible.cfg and populate it manually?
Are there starter templates?
Well, first of all, stop asking questions so quickly.
But yeah, so what this is talking about or what I'm speaking to is a command.
I'm just going to add it to this file temporarily.
If you do an ansible‑config init, note that you can specify the path,
and that can be anywhere in your file system.
It does have to be called ansible.cfg.
But the disabled parameter here, this flag,
gives you all of the starter values that are all line commented,
and they're just all disabled by default.
Make sense?
All right,
so the main ones that are really in scope at the fundamentals
level are these ones that I brought to the top,
the default root path for Ansible config files.
And I've specified‑‑‑ Here again, interestingly,
on this controller, I'm operating out of my current user directory,
which is a little bit non‑standard I must say.
And that's why it's important to have these Ansible CLI commands
at your ready reference so that you can quickly run and verify
where is your config file that's active,
where is your inventory source, etc.
And that's again the inventory keyword.
All right, so speaking of inventory, we've used that word a whole lot,
haven't we?
I'm going to, let's see.
I'm going to do a file, I'm in VS Code, Open Folder, and check this out.
Because I'm in my WSL session.
I'm browsing the file system of the Ubuntu server,
which I just am tickled about that.
And I'm going to do etc/ansible.
What gets a little bit annoying and a little bit takes some getting used
to is that when you're using WSL in Visual Studio Code,
you get new instances of the application every time you open a new folder.
That can be a little bit‑‑‑ Well, it's disconcerting for me.
I don't know if it's disconcerting for you.
But I opened that etc/ansible to get my host's file,
and I want to ultimately show it to you,
walk you through it, as we're proceeding through this demo.
We also can clean it up.
It's kind of ugly the way it is right now.
Does the file have to be called hosts?
No, absolutely not.
You can call your inventory files whatever you want as
long as Ansible knows where to find one.
And it does need to be in a valid INI or YAML format.
I prefer INI because of its simplicity.
When you install Ansible, depending on the distribution,
depending upon how you do it,
you may get a sample hosts file in the default location,
that's the Ansible, that has a bunch of examples.
That's what you're seeing here.
So we have all of these commented lines that show us different
techniques for organizing your managed hosts.
Now understand that just because this course is focusing on Windows,
remember macOS and Linux and hardware devices.
So a common thing is to have a single inventory file where your
different platforms are represented as groups.
And you can even, as you see here in this example,
if you have multiple hosts following a pattern,
you can specify them.
So you're using what looks similar to regular expression
syntax to iterate and make your entries in your inventory
more compact yet more dynamic,
especially if you've got just incrementing host names as that shows.
So again,
this may take some getting used to for a Windows systems
administrator because we're not accustomed,
I'm one myself, we're not accustomed to horsing around with these text files.
How flexible are these?
Well, as it happens,
they're very flexible and especially if you're committing the
changes into source control so that you've got all of that
visibility and history and so on to work with.
So in this example, my host file,
I've got my control group that right now consists of just a single machine.
Well, I'm now going onboard another machine.
Its host name is node1.timw.info.
That's its actual DNS name.
But remember, we can alias this to node1 or n1 or foo if we want to,
as long as Ansible can eventually get to it.
So if you're going to alias a name in your inventory,
throw in ansible_host,
and then we can add the actual IP address or DNS name for that host.
So that's a useful technique.
But what we don't need here is this web section.
I was going to have more machines,
but we're just going to go with this right now.
And then a useful way to make the hosts in your inventory more dynamic
and so forth is to create a variables block for them.
And this is important.
We're going to talk about what all of these options here
mean in the final module of the course,
but let's actually discuss a little bit of it right now.
The variables are optional, please understand that,
in many cases and then required in others.
This is an example of where it's required.
Because we're in an Active Directory environment, we need Kerberos.
We're going to use WinRM on 5986 using TLS.
So we've got, as you can see, these are all reserved variable names,
ansible_user.
What is the Active Directory cert or local account
identity that you're going to use?
You're probably not going to do ansible_password here.
We're going to invoke that in the playbook,
and we're going to integrate by fetching the password in Ansible Vault.
We never want the password in plain text.
So yeah, we're specifying WinRM on 5986.
I'm set up.
The controller has Kerberos installed.
That's actually something else I can show you.
We've got Kerberos.
And in this case, when you just do a garden variety setup for Ansible Windows,
which consists basically of just running an Ansible‑provided PowerShell script,
it opens the listeners for WinRM and so on.
But once you've got all of those t's crossed and those i's dotted,
it's just a question of specifying the appropriate defaults here.
But as you can see, I'm choosing to ignore self‑signed certificates.
Again, when you do a garden variety WinRM setup,
you're going to use a self‑signed certificate to support TLS.
In the real world, you likely have your own public key infrastructure,
whether it's Active Directory Certificate Services or another solution.
So it should be, quote unquote should be, relatively trivial for
you to lock down that traffic using TLS certificates that are
trusted within your organization.
All right‑o‑reno, so this is looking good. I guess we can finish.
Let me save.
And here again is a little extra tip. Just to review, to set up Visual
Studio Code to work with WSL, you need to get WSL on that machine, of
course. You need to install the appropriate extensions,
particularly the WSL extension for Microsoft. And once
you've done that, you can open WSL.
In fact, if you go to View, Command Palette and just type WSL,
you can get a list of extension‑specific commands.
I actually installed another extension I want you to be
aware of that is a big headache saver.
And that is uh oh, thought I had it installed here.
Let me see.
I thought I did. Another nice thing‑‑‑ There it is.
It's called Save as Root in Remote.
This is such a great extension because normally the way VS
Code works with least privilege and so on,
you're not able to save your changes or sudo natively.
So once you install that extension, I now can do a Command Palette, Save as Root.
It may ask me for the root password,
which I have. And then it now has saved that inventory file.