- [Instructor] We'll want to begin taking a look here
at some orchestration tools used for network automation.
The exam blueprint tells us that we simply need
to compare the features of these tools
and not necessarily have an in depth knowledge
of the inner workings,
so that's what we'll do, starting with Chef.
Chef is an open-source tool
that is used to automate network configurations.
When creating code in Chef,
the Ruby programming language is used.
Ruby has been around for quite some time
and is designed as a general purpose programming language.
This is an object-oriented programming language
similar to Java, Python, and C++, just to name a few.
Tools, such as Chef,
that are used for configuration management,
generally function in two different models.
They are either Push models or Pull models.
Push models will send a configuration out to other devices
from their centralized management base
while Pull model means that the client nodes
are dynamically updated and they pull their configurations
from the management server.
Chef uses the pull-based approach for orchestration.
Chef requires three core components for operation,
the Chef server, a Chef workstation,
or multiple work stations, and the client nodes.
The Chef server is the central point in the topology,
and this is where the configurations are stored
and also the place that the nodes in the network
will communicate with in order to pull down configurations.
The web interface is known as Chef Automate,
which replaced the previous version
which was called Chef Manage.
This is where you can log in through a browser
to take a look at things on the server itself.
The Chef server has load balancing features
that will allow it to handle
thousands of nodes simultaneously.
The backend of this database on the server
is essentially a SQL server used
to handle all of the information.
The workstations themselves are where configuration policies
are created, managed, and tested.
This can be a single workstation
or that can be multiple workstations
if you have multiple administrators
who need access to the Chef server.
Any created policies or changes here
are pushed out to the Chef server,
and the nodes would be the network components
that are being managed by Chef such as servers.
Each node would have a Chef client installed
which would communicate with the Chef server.
The Chef client is responsible for the pull action.
Remember we mentioned earlier that Chef uses a Pull model,
so this client pulls down configurations
to the nodes and applies them.
These can be storage devices, containers,
or both physical and virtual servers.
Lots of flexibility with what Chef can manage.
There is some terminology used within Chef
that you'll want to be familiar with as well,
starting with a Recipe.
A Recipe is written in the Ruby programming language,
and it contains configuration information.
Each of these recipes must be contained
within something called a Cookbook,
and cookbooks are simply collections
of recipes and other files.
These cookbooks are used
to facilitate automated network device provisioning.
The great thing about this is
that you can create Ruby-based cookbooks and recipes
to completely provision new devices automatically.
All you have to do is connect a node into the network,
install the Chef client, and then let Chef do its magic.
On the workstation, there's a directory
called the Chef-Repo Directory,
short for the Chef Repository.
This is where the cookbooks themselves are created.
The workstations will push out the cookbooks
from the Chef-Repo to the Chef server
where the Chef server stores the cookbooks
in its own repository called the Bookshelf.
The cookbooks are pushed from the workstations
to the server using the Knife Command Line Tool,
and the knife tool is the primary way
that a workstation is able
to communicate with the Chef server.
This is how the contents of the Chef Repository
on the workstations are pushed out to the server.
Knife does require an RSA private key
because every push to the Chef server
is authenticated through an RSA public key pair
for security.
The Chef server will hold the public key
while the workstation holds the private key.
And, by the way, if you have a familiarity
with the Linux Command Line,
that's going to go a long way when you're using Knife,
but there are also lots of helpful command guides
that you can find online.
There's also something on the workstation
called the Test Kitchen, which you can probably guess,
allows you to test out your cookbooks and recipes
before you push those out to the Chef server.
So that's a basic overview of the features and functions
of the Chef automation and orchestration tool.