Male Instructor: Puppet refers to systems it
manages as nodes.
So far we haven't had to specify which nodes we
want our Puppet code to run on.
That's because we've been using the Puppet apply command
which always applies the code you specify
on the node where you run the command.
It doesn't do any kind of checking
to see if this is the right node for this particular code.
For example, in a real network you wouldn't
want your web servers to have the same configuration
as your application servers, or your database servers.
So you would need to have some way to tell the Puppet server
which nodes should get which configurations.
Puppet refers to this as classification.
When you classify a node you're saying which classes
should be applied to that node.
For example, you could have a class called web server
that contains all of the configurations
that should be applied to a web server.
Then you would need to tell Puppet
which of your nodes are web servers.
The easiest way to do this is using node definitions.
I'm going to show you how to do this
with the test VM we've been using.
We're going to tell the Puppet master
which class it should apply to this node.
Don't worry about the fact that our Puppet master
is on the same server as the node we're classifying.
This is just a special case where the Puppet master
is managing its own underlying host.
Node definitions go in a special file called site.pp.
Which is the main manifest for this Puppet master.
It needs to go in the manifest directory
for the production environment.
This directory is empty to start with,
so we'll create the site.pp file.
A node definition is quite simple.
You just type node,
then the fully qualified name of the node in quotes
which is puppet.test.vm in this case,
then a curly brace.
Now we just include any classes
that should be applied to this node.
So we'll say include motd setup.
Then we just put a closing curly brace
on the next line and we're done.
Now we'll save the file.
Okay, please note that if we were adding any node
other than the one where the Puppet master resides
then we would need to perform a couple more steps.
We would have to install the Puppet agent on the node.
We would also have to sign the node's SSL certificate
on the Puppet server.
We won't be covering that process in this course.
So we'll just run the server and the agent on the same host.
Let's get back to running Puppet on this node.
How do we do a Puppet run that uses the site.pp file?
There are three ways to do a Puppet run.
So far we've been using the Puppet apply command
to do all of our Puppet runs.
This doesn't use the site.pp manifest
and it's not how you would run Puppet in production.
It's time to learn about other ways to run Puppet.
In a production network you would install the Puppet agent
on every host that you want Puppet to manage.
By default the Puppet agent runs every 30 minutes
to ensure that the hosts configuration matches
what the Puppet master says it should be.
To start the Puppet agent you use the command Puppet agent.
In production you would put the Puppet agent
in the startup scripts on each hosts
so that it would run at boot time.
We're going to use the Puppet agent but we're going to
run it manually to make it easier to see what it's doing.
And so that we don't have to wait for the next automated
30-minute run to test our changes.
The way to do this is to add the -t option
to the Puppet command.
Minus t stands for test because you use this option
when you want the Puppet agent
to run once and then shut down.
Without further ado, let's give it a try.
If you get more lines of output than this
then don't worry; that's normal.
Well it ran successfully but it
didn't actually apply any changes.
That's because the motd file has hello world in it.
So Puppet didn't need to change anything.
Let's change the contents of the motd file
just to make sure Puppet will actually fix it.
We'll just remove world.
Now we'll run the Puppet agent again.
This time it printed some extra lines
saying that it defined the content in etc motd file.
Let's double check.
It did.
Now it might not seem like we really
accomplished anything new because we just got Puppet
to do exactly the same thing as before.
That is put hello world in the motd file.
But the difference is that when we
used the Puppet apply command before we had to tell it
which class to apply.
This time with the Puppet agent -t command,
we didn't tell it which class to run.
It had to figure that out by
looking at the node definition for this host.
There's just one more thing before we move on.
If you define any nodes in site.pp
then you must define them all.
That sounds a bit daunting.
I mean what if you forget to include one node
and now Puppet won't run at all?
There's an easy way to make sure that doesn't happen.
You just add a default line to site.pp
as a catch-all for any nodes that aren't explicitly defined.
Here I'll show you.
The only tricky thing is you have to remember
to not put quotes around default because
it's a special value.
If you don't want Puppet to do anything to a node,
if it isn't explicitly defined, then you can just
leave it blank in between the curly braces.
Of course, since we only have one node
in our Puppet network we didn't actually
need to add the default node entry.
But it's still a good idea just in case we
do add more nodes later.
That's it for this lesson.