All language subtitles for Free-CCNA-Ansible-Puppet-Chef-Day-63-CCNA-200-301-Complete-Course_en

This is a free, complete course for the CCNA.

If you like these videos, please subscribe\n

Also, please like and leave a comment, and\n

In this video we will cover configuration\n

They are exam topic 6.6, which says you must\n

So, just like with the other automation topics\n

be able to use these tools yet, but Cisco\n

of their purpose and capabilities.

Here’s what we’ll cover in this video.

First I’ll introduce configuration management\n

Then I’ll introduce some of the characteristics\n

So far I’ve introduced various automation\n

They are suitable for some jobs, and not suitable\nfor others.

Depending on the company you work for and\n

automation tools, or just a few of them, or\nnone at all.

Configuration management tools like these\n

in medium to large networks with hundreds\n

And make sure to watch until the end of the\n

Software’s ExSim, the best practice exams\nfor the CCNA.

To understand one reason why configuration\n

the concept of configuration drift.

Configuration drift is when individual changes\n

to deviate from the standard and correct configurations\n

This is not a good thing, and should be avoided\n

I mentioned this earlier in the course, but\n

have a totally unique configuration.

Although each device will have unique parts\n

and its host name, most of a device’s configuration\n

by the network architects or engineers of\nthe company.

For example, you can expect all of your routers\n

same Syslog configurations, the same AAA configurations\n

one or two LAN interfaces, etc.

Those all follow standard templates, with\n

But, as individual engineers make changes\n

fix network issues, test configurations, etc,\n

Often records of these individual changes\n

can lead to issues in the future.

For example, it might be hard to tell if a\n

The configuration management tools we’ll\n

without automation tools like Ansible, it\n

For example, something I did in the past was\n

a text file and place it in a shared folder.

In my case, a standard file naming system\n

Notice in the screenshot here we have three\n

different dates, and three versions of R2’s\nconfig as well.

This helps keep track of previous versions\n

However there are flaws to this system, as\n

new config in the folder after making changes.

In that case, which one should be considered\nthe correct config?

And even if the configurations are properly\n

guarantee that the configurations actually\nmatch the standard.

It just helps us keep track of different versions\nof the config.

Plus, a manual approach is not very scalable\n

So, configuration management tools can of\n

like preventing configuration drift, but they\n

Configuration provisioning refers to how configuration\n

This includes configuring new devices too,\n

As you know, traditionally configuration provisioning\n

via SSH, or console as well of course.

But this is not practical in large networks.

It simply doesn’t scale well in networks\n

Configuration management tools like Ansible,\n

to devices on a mass scale with a fraction\n

Two essential components that you’ll find\n

Here’s an example of a template, where values\n

IP address, mask, OSPF process ID, and area.

Instead, we use a separate file specifying\n

Given a template and the appropriate variables,\n

Of course, this is just a small snippet of\n

easy it would be to generate the configuration\n

All devices can share the template, and we\n

Exactly how these templates and variables\n

tool, but they all use a system like this.

Okay now let me introduce configuration management\ntools.

These are network automation tools that facilitate\n

They can be useful in networks of any size,\n

The options you need to be aware of for the\n

When it comes to managing network devices,\n

Ansible first, Puppet second, and Chef third.

However, these tools weren’t originally\n

They were originally developed after the rise\n

automate the process of creating, configuring,\nand removing VMs.

But these days they are also widely used to\n

They can be used to perform tasks such as\n

Using templates it’s very simple to generate\n

They can be used to perform configuration\nchanges on devices.

It can be all devices in your network, or\n

You tell Ansible or Puppet or Chef which changes\n

does the rest of the work for you.

These tools can also be used to check device\n

If a device’s configuration doesn’t match\n

Then you can investigate that issue and fix\n

Or you can automate the change.

You can also compare configurations between\n

configurations on the same device.

These are just some examples of what you can\n

Basically, they solve the problem of managing\n

with hundreds or thousands of different devices.

Now let’s take a look at the basic characteristics\n

Ansible is a configuration management tool\n

Ansible itself is written in Python.

The other two I’ll introduce, Puppet and\n

It means that it doesn’t require any special\n

Instead, Ansible simply uses SSH to connect\n

This is a big advantage of Ansible which makes\n

reason that it is the most popular choice\n

Ansible also uses what’s called a push model.

The Ansible server, also called the control\n

and push configuration changes to them.

This is different than Puppet and Chef which\n

connect to the server to receive their configurations.

After installing Ansible, you must create\n

Playbooks are the ‘blueprint’ of automation\ntasks.

They outline the logic and actions of the\n

Then you’ll also need inventory files which\n

as well as their characteristics.

For example, their device role such as access\n

etc can be listed as a characteristic.

These inventory files can be written in multiple\n

You also need templates, which as you saw\n

but specific values for variables are not\n

These templates are written in a format called\nJinja2.

And finally you’ll need variable files.

They list variables and their values, as you\nalso saw earlier.

These values are substituted into the templates\n

these files are written in YAML.

Let’s look at a diagram to visualize how\nthis works.

So, here we have our inventory, templates,\n

The inventory provides a list of devices,\n

for the devices, and the variables provide\n

These inputs are given to the playbook which\n

You should know that it is agentless, written\n

connect to devices, and uses YAML for its\nnecessary files.

Puppet is a configuration management tool\n

It is typically agent-based, which means that\n

installed on the managed devices.

And not all Cisco devices support a Puppet\n

is more popular for network device management.

However it can be run agentless, in which\n

the proxy agent uses SSH to connect to the\n

Note that in Puppet the server is called the\nPuppet master.

And Puppet uses a pull model, so clients pull\n

of the Puppet master pushing configurations\nto them.

And note that clients use TCP 8140 to communicate\n

You probably should remember that port number.

And instead of YAML, it uses a proprietary\n

Like Ansible it requires some different text\n

Manifest file defines the desired configuration\n

The Puppet master then uses this Manifest\n

And just like Ansible, templates are used\n

Here’s a very simplified look at that.

Note that some of the devices have a Puppet\n

to communicate with the device, but one doesn’t.

Instead it will communicate via the external\nagent.

In both cases, the network devices are able\n

Remember that it’s written in Ruby, is typically\n

master, it uses a pull model, clients use\n

it uses a proprietary language for its files\n

the desired configuration state of devices.

Those are the main points you should know\nabout Puppet.

Like Puppet, it is a configuration management\n

It is agent-based, so specific software, a\n

And not all Cisco devices support a Chef agent,\n

So, this is the least popular of the three\nchoices.

Like Puppet, Chef also uses a Pull model.

And the Chef server uses TCP port 10002 to\n

It uses various other ports, too, but you\nshould remember 10002.

And Chef’s files use a DSL, Domain-Specific\n

So, what are some of those files used by Chef.

We have resources, which are like the ingredients\nin a recipe.

They define configuration objects managed\nby Chef.

A configuration object could be, for example,\n

Then there are recipes, like the recipes in\na cookbook.

They outline the logic and actions of the\n

And of course there are cookbooks too, sets\n

And finally run-lists, which are an ordered\n

to the desired configuration state.

And here’s a diagram from the Chef website\n

Admins will do their work on a Chef workstation,\n

Required information is stored on a Chef server,\n

communicate with the Chef server.

Notice that possible clients include servers,\n

clouds, and of course network devices.

As mentioned earlier, these tools weren’t\n

and they can be used for various purposes.

Remember that it is written in Ruby, is agent-based,\n

configurations, and its files such as cookbooks\n

And finally, here’s a chart comparing the\nthree.

Something I didn’t mention clearly is that\n

I recommend memorizing these basic characteristics\n

Okay, here’s what we covered in this video.

I introduced configuration management tools\n

And then I introduced three that you should\n

We only covered some very basic characteristics\n

As you continue your studies you’ll probably\n

especially Ansible, but for now you just need\n

And make sure to watch until the end of the\n

Software’s ExSim, the best practice exams\nfor the CCNA.

Okay, let’s go to quiz question 1.

Which of the following configuration management\n

Pause the video now to select the best answer.

Okay, the answer is B, Ansible.

Ansible is agentless, so the control node\n

Now, a Puppet external agent also connects\n

architecture does not, so Ansible is definitely\n

Which of the following configuration management\n

Pause the video now to select the best answers.

Okay, the answers are A, Chef and C, Puppet.

They both use a pull model, whereas Ansible\nuses a push model.

Which of the following configuration management\n

Pause the video now to select the best answer.

Okay, the answer is D, all of the above.

Now, in this video I didn’t explicitly state\n

model, but in describing their operations\n

Which of the following configuration management\n

Pause the video now to select the best answers.

Okay, the answers are A, Chef and C, Puppet.

Both of these tools are written in Ruby, whereas\n

Okay, let’s go to question 5.

Which of the following configuration management\n

Pause the video now to select the best answer.

Okay the answer is B, Ansible.

Ansible playbooks are the blueprints of automation\ntasks.

They outline the logic and actions of the\n

Okay, that’s all for the quiz.

Now let’s try a bonus question from Boson\n