Now just in the same way as when we looked at Ansible,
we had ad hoc commands that could be issued directly from the command line,
we have the same in Puppet.
We don't need to create a manifest,
we can issue commands directly from the command line.
Now we will be creating a directory,
this is going to be for files that we work with later,
but we can go through and issue commands directly from the command line.
Here we're making sure that the chrony package is installed.
We can make sure that the chrony service is up and running and it's enabled.
But be careful.
Obviously the keyword differences are a little bit confusing
when you've got to deal with multiple systems.
So instead of started, we have running, and instead of enabled, we have enable.
So just be careful, these are easy to trip up on.
We can even go through and create a record for our host.
So if I want to then go through and easily be able to
connect through to my Red Hat machine,
I can add in a record to my etc host file with the IP address.
If I take a look at all of those resources,
we'll be able to see that they have been added.
I will print essentially my etc and host file.
So why don't we go through and just take a look at the command line
and look at applying local Puppet configurations,
so installing software, managing services,
and adding in host entries?
Now again, we're working at our command line,
and we're able to demonstrate with puppet apply and the option ‑e that
we can apply ad hoc commands without the need of having to embed our
code into some sort of configuration file.
Those files in Puppet are known as manifests,
but we can look at operating it directly from the CLI
without having to create those manifests.
If we take a look inside of our Git repository and
the CompTIA puppet subdirectory,
any manifests that we do work with we have provided ahead of time.
As always,
it's far better that when we need these manifests that you create
them for yourselves rather than just copy and paste.
We can create our directory for manifests.
We can create it, let's say, just as puppet,
but we don't need to deal with our manifest directly at the moment,
we're going to concentrate on running commands just to apply configuration.
Now this has all got to be done as root so I'm elevating my privileges.
And we can go through then and run puppet apply.
Puppet apply is just using the agent, we're not using the server.
‑E allows us to execute a command without having a manifest,
but then we have to describe it on the command line.
We want to work with _____ package, so we're going to install a package.
The package name, we're going to make sure that chrony is installed,
our time server.
Once we've got our name, we put a colon and set the properties.
So we want to ensure, and then use the big arrow key,
and we're going to put installed.
We're finished with this now, so we close off our brace brackets,
close off our single quotes, but you can see,
because of our version of Puppet, we're getting a whole load of warning messages.
If I do a Ctrl + C, I can end this.
It's going to be far clearer to see what's happening by just
redirect error messages through to dev/null.
If we then go through and re‑execute,
we're only going to see then our standard output.
Now we can see what's happening in the background here,
and there weren't any changes that were needed,
we had chrony already installed, we had installed it previously with Ansible.
But we probably also want to check that the service is up and running,
so we can go through then and use service,
it's still the chrony service that we are dealing with on Ubuntu,
and we want to then for our state we use ensure,
but this time the state is going to be slightly
different to what we've used previously,
it's going to be running.
Now we want a list of properties now because we want it running,
but we also want it enabled,
so we have the property enable and then hash arrow true.
This is a boolean, so it's not quoted.
So we can see now again the service was up and running.
We can check from the chronyc client, so chronyc and sources,
we can see then the list of servers that we are synchronizing with.
And of course then this was set up previously when we looked at Ansible.
Now as well as dealing with our standard resources,
a nice resource that we have is our host resources.
These are local host records.
If I just look at printing out with puppet resource and host,
we see the contents of the hosts file.
Whilst this is stunningly exciting, it's nothing we couldn't do with cat.
But what becomes really useful is I can then go
through and create new host records.
Now of course on a single host it's not particularly useful,
but if this was a manifest being applied by a server to the agents,
this would be incredibly useful.
So we can then go through and put our host resource,
the name now is going to be the host name that I want to add,
so I'm going to add in redhat,
and then we want to make sure that we've got the IP of the
Red Hat‑based system that we are using.
So I'm going to go through, clear all of this out,
and then ip, hash arrow, and then in quotes the IP address,
which in our case is 192.168.56.11.
Hit the big Enter key on this,
and this time we can see that we're getting the created coming back,
so we have made a change.
Now it's very easy then to duplicate this, to up arrow key.
Change our IP address to 12 and this would be our suse host,
and then of course go and change our name through to suse.
Hit the big Enter key, and again,
we're going to see then that the new record was created.
If we go through and print out our host file again,
we can see the redhat and suse entries.
But what does that mean to us practically?
Well, then I'm able to ping the Red Hat system.
So there you go.
We've seen the very basics of using Puppet from the command line, using our puppet apply and ‑e.