So yes, we need to learn how to work with our Salt states.
So we're going to be modifying our vim modeline,
creating state files, and then applying our state files.
We'll also take a look at the documentation,
make sure we understand the difference between our remote
execution and our state documentation.
Hey,
I really hope you're ready for this because we're about to learn
a heap about working with our state files,
our consistent configuration.
So what we're going to do first is make sure we
understand about the documentation.
So if we go back to salt‑call, ‑‑local, and sys,
but instead of just list modules,
we're going to go through and do list_state_modules.
Our remote execution modules are different to our state modules.
So this is a list of all of our state modules.
And again,
if we want to check then the functions, we can use
list_state_functions, and let's just take for the idea the
package module. Now, within a state file,
we would use pkg.installed to say the desired state, or we
would say something like pkg.removed. So we can see the names
of the functions can differ as well.
Now let's go ahead and start creating our directory to house our state files.
So. /srv/salt.
This would be the same on the server, as well on the minion.
Now, we're going to be working with our files locally, and we're
going to be adding them to the Salt files later because that allows
us to use the vim modeline, and we're going to go in and set this
up inside of our .vimrc file.
So as our standard user, we can go through then and put our
bg=dark and our modeline, and save that.
This works for a standard user, but it doesn't allow you to
use the modeline when we're the root user.
Hence, we're editing our files locally and copying them across later.
But what we're going to do now is create our .sls file, or at least the
first line of this. And the first line will be our modeline.
The modeline is configuring vim, and we'll have the correct settings that
we need. Now, because the .sls file is not going to be recognized on our
system, this is why we are using the modeline configuration, and you're
going to see that it works really well.
Now we've already discussed this within the slide, so I'm just then
going to paste it in directly from the slides.
It's writing through to the common.sls file in my current directory,
but we're going to see what it's done for us and how it's going to
help us by editing the file straightaway.
So we're going to open it in vim.
So, vim and common.sls. We can see the syntax highlighting is working for
me. We can see this is a comment. It's read by vim,
it's not read by anything else, but we can see how it's going to help.
The first thing we have for our state is a state ID.
This uniquely identifies the state in the state file.
I'm just going to call it install common software.
Just try and keep it as descriptive as possible.
Then we've got our module.function, so pkg.installed.
If we want multiple packages installed, we can go through and use
the pkgs and have this then as a list of packages.
Remember, list items in YAML just start with a dash.
So we can have things like rsync, we can have curl, we can go through and
have our vim data, remember, we needed that to make sure that we had our
syntax highlighting, and we can go through and use git. These are all
package names that work on openSUSE.
But as well as installing packages,
there's a lot more that we can do. And we can have multiple states in a
single state file. So I can just move back, and we can see how my cursor
is really useful, especially that column,
making sure then that I'm lined up correctly, and I can
set up a new state ID. So, Configure TZ.
I'm just keeping it short here, but try and keep it descriptive. And
with this, then, we're going to use timezone.system.
So the system function from the time zone,
the module. Setting up the key utc to be True will just ensure
that the hardware clock is set to UTC time,
but we want our display time to be correct so we can
configure the correct time zone.
So I do that with the name, and then obviously you can configure
whichever time zone works for your system.
So mine,
I'm just putting Europe and London. Now, obviously, I
could put more in, but with this done,
I can go through and save my changes, and my common file is ready. But remember,
it's still in my home directory,
so I'm just going to copy it across, put then our common.sls into /srv/salt.
This directory is known as our file roots, and where the agent is going
to search for the state files. We could apply it with salt‑call ‑‑local,
and we can go through then and use the state module .sls function, and
we've referenced just the name, not the extension, of our state file.
If we don't want it applied, we can use test=True.
It will then go through and show what it would do if it were allowed.
So we're going to leave this to run through its wicked ways, but it's not
going to make any changes, it's just going to report. And we can see all
of the packages were in the required state,
but our time zone wasn't, so would have changed. If we're happy with
that, we can go ahead and execute without the test=True, and of
course then, we're going to do exactly the same as we did before,
but instead of just reporting,
we're going to carry out. We can see the blue data
saying that the time zone was changed.
And again, the idempotent nature means if I run it when
everything meets the required state,
we don't produce any errors, we just say that we didn't need to
change anything, everything was in the desired state.
So we've seen then how we can configure our Salt system working in a masterless
environment, and we've even written then our state files. Let's just summarize this a little.