Cisco CCIE Security 350-701 – ANSIBLE- COnfig MGMT Tool

1. ANSIBLE- COnfig MGMT Tool

Now in this section we’ll try to understand the ensile config management tool and also some terminologies later on in the next coming topics we’ll also see the terminology and other concepts. So starting with Ansible, ansible is again another automation tool which is capable of doing the configuration management. Again the configuration management is the same thing what we discussed where you can make some changes to the end devices, the nodes and these devices probably you can send those configurations back to the end nodes in the form of config files. So that’s what we call as configuration management. You can centralize the configuration management from the control stations or from the server. Generally we call it as a server and once you make the changes of course we do this in the form of scripts that is nothing but the confirmation files.

Now, once this conflation files have been sent to the nodes for ensuring that the changes occur on the nodes now it also helps you to monitor the conflation changes. The monitoring is nothing but checking whether whatever the device configurations you want to apply it exactly matches your requirements on each node. So same like rest of the tools. Apart from that it also helps in deploying the applications. Now, deploying applications is like simple way of deploying your applications on the remote devices, on the remote nodes using a common framework we can say like deployment manager kind of thing and apart from that you can also do some kind of automation of your cloud provisioning. Now, most of the organizations generally they use some kind of cloud environment where they host their applications or host their data problem. You can also do that automation where you can say automate automate the tasks which are relating to cloud provisioning.

So instead of using the manual options so this will apply to again whether you are using a private cloud or a public cloud environment. So Ansible is again popular due to open source. Now again, open source is like the free open source version which everyone can use, that is one option or you can also go with something called paid ansible version called Ansible tower software which can install so you can get some more additional features and the benefits compared to the open source. Apart from that it is popular because of its simplicity because it is easy to deploy, it uses something called YAML language which is more simple and more easy human readable kind of language while you’re writing the scripts or the configuration file.

So that makes Ansible little bit more popular compared to the other ones like Ship or Puppet. And again one more benefit you get where here is it is an agent less tool. Now, in the previous sections we have discussed the difference between the agent based on the agent based you need to have an agent software to be installed on each node but practically having an agent softened on each and every device is not really a possible option. Like maybe you have some Cisco routers or some Cisco devices. They don’t support an agent tool on that. So with the help of Ansible, even though these are like simple routers or simple nodes, there is nothing like agent kind of tool. You can still push the configurations from the server so there is no need of any kind of software or the agent required on the client machines.
Unlike puppet or chef. Puppet and Chef uses agent based. You need to have an agent software on them. If you remember in the previous sections I discussed separately on Puppet and Ship features. Now apart from that, again it is going to use SSH because most of the end nodes like if you take a normal with our Cisco environment, if I’m using routers or switches and if there is no agent based tool then how the communication is going to happen. It uses something like SSH which is normally supported on the devices for remote management, for CLI based management. And again if you are doing some kind of server management you can also use something like Windows remote management option which allows you to run the scripts remotely. Probably that is one option. And additionally you use some other transport mechanisms like there is something called NETCONF net confused to make some changes and extract some information from the networking devices.

So these are some of the options which are used because they are agentless. So there will be there are some alternatives to do that. And then Ansible uses push model. Now push model is like the server or the ansible station. The server is going to push the configurations back to the end nodes and again the server is going to initiate the connection and then all the configuration files will be pushed onto the end nodes. Okay? So the nodes will be getting the configurations from the server directly. And these configurations you can either manually you do it at that point of time or there are options like scheduling, you can also schedule them to run later on at a specific interval of time.

Now one more thing, we have Ansible send all the requests from the control station which could be a laptop or it can be a server. Now this exactly means here we have a concept of control station. Now this can be any device like maybe you’re using your company laptop or personal laptop where the software is exactly installed, the Ansible software is installed or you can install that on a specific dedicated server as well. So typically console station is nothing but any device which has Ansible software installed and you can use this particular device as a control station. Okay? So typically this device will be mostly based on Unix, linux based code. If you’re using your Windows machine, probably you will be running inside the VM because it has to use this Linux or Ubuntu kind of codes probably so you can use use your own devices for that. This control station from where you are going to manage your endpoints and probably in your network, you can have more than one.

2. ANSIBLE- Control Station

Okay, now we’ll move on with the Ansible terminology concepts. Now there are multiple things we’ll see here. The first thing we’ll start up with the control station. Now the control station is nothing but from where Ansible is going to send out all the requests and this device can be any device like a laptop or a server running. So if you remember in the previous we have discussed in the shift protocol probably the ship management tool, the config management tool. Basically in the ship we have something like Workstation concept. Now this Workstation can be your laptop from where you can create the code or you can write the scripts and then probably you can upload them to the server. That is what we call a ship server. And then from the server again, it is going to push those things back to the nodes, it’s going to send out to the nodes and the confirmation will be applying on the end nodes through the server.

Again, in the puppet config management tool, again, we have just a server over there, we call it as Puppet Master and this master is going to send out the nodes and there is nothing like Workstation or the host. So it has to be a puppet server where the software is installed. But when you compare this with a control station, probably in Ansible, in Ansible you have a host and that host is installed with the Ansible software and technically we call it as a control station. And this control station is going to send out the confirmation back to the nodes. So which means there is no concept of we call it as master here.

And this host can be any of your computer. Like you can run a laptop which is installed with the Ansible software, probably in Linux or Unix code or if you’re using Windows machine probably you can install in the form of VM from where you can send out the foundation files directly onto the nodes without having a master. So this is something different. If you remember in the previous we have seen these concepts of master like puppet master and ship server options.

But whereas here Ansible doesn’t have any kind of master load, so we don’t have a master load here. So it’s like the direct host from where you are sending the config files directly to the network nodes and that particular host or the device we call it as a work control station here. Now probably again in the in your network you can have multiple control stations as well. And then finally it can run from any host. Any host means it can be on any operating system.

3. ANSIBLE- PlayBook-Inventory

With some other concepts. Like in this, we’ll try to understand something called playbooks and inventory list. Now, first we’ll start with the playbooks. The playbooks refers to the same configuration files. So confirmation files which are like the configurations you want to apply on to the end nodes. And these confession files are created on your control server of the control station from where you are going to send out this to the end nodes using some kind of SSH access onto the remote devices. Okay? So technically the same names. If you remember in the Puppet we have used something called manifest. That’s the name used in the Puppet, the concentration files. Again, if you’re using Chef tool, probably it’s referred as a recipe. And similarly, if you’re using Ansible, the same technical name used as a playbook. So in terms of whatever the definitions we learned in the config files. So the same thing you can apply here, the names differ, the names are different in different tools.

Again, and the language which is used to write it is different. It’s going to use something called Yanam YAML, yet another markup language. That’s the language used to write the confirmation files. If you compare with the previous, like in Puppet and Ship, they use something called Ruby language. Here it is different. YAML, yet another markup language. Now, what this config file do? Let me quickly review. Again, these config files are responsible for providing what are the configurations you are going to apply onto the end nodes. So it’s kind of set of commands or the scripts, what you want to apply, the exact configurations you want to apply onto the end nodes which are being pushed from the control station. So here we call it as a control station in Ancient.

So what are the set of commands you want to execute? What are the list of the things you want to do, list of the things or list of the task you want to execute onto the end device and written in YAML format.

And generally you will have an extension of something like YML format. So these playbooks will have YML extension in general. Now, let’s try to see one more thing in this like inventory. Now, the inventory is the list of devices. Now, inventory means like devices. That’s a common name used. And technically the list of the devices, we call it as inventory list or inventory here.

So what it will do, it is going to provide the device information like the host names it is going to manage. So along with each and every device information and each and every device roles, because Ansible, when it is working, it is going to work with multiple nodes. There are multiple hundreds of nodes in your infrastructure. And at the same time it is going to make a list of those nodes or group of lists, we can say and what are the services they host or what they do. And what are the rules of each and every node that information will be maintained inside the separate file. We call it as inventory file. So you can see inventory file is going to keep a track of the host or the end notes it’s going to manage and in these files we have all the information like device host names and information about what they exactly do, what are the roles and what are the services they are going to offer in your network. And these inventories can be in any formats probably depending upon the plugins.

So there are some specific plugins you use in your network depending upon that these inventory files can be in different formats and the most common format you will find is something like ini ini and YAML formats. So these are like common formats list you will see so if you try to see one of the sample files here, here you can see this is the inventory file list where you have specific routers with these IPS and then these are the switch IPS and then the gateway information. So typically you see this is how the format looks of the inventory file and on the left side you can see there is another Playbook format. So Playbook is your actual config file file you are going to apply which includes the configurations like you want to assign the IP address and use no show on command and of course you want to use the username and the password to log into those devices.

4. ANSIBLE- Templates-Variables

Here we’ll try to understand some of the other concepts relating to ansible like there is something called templates and variables. So they are a little bit interlinked with each other so probably we’ll try to see both at the same time. Now the technical definition like template is a kind of ansible file which contains all the device configuration parameters us with variables. Now to understand this, let’s take an example. I do have the configuration and I want to apply this configuration to multiple servers. Let’s say we got server One, server Two, server Three, server for server five and for all these servers I want to do some kind of configuration. So maybe I want to apply a specific configuration for each remote server and we are going to create some configuration files for that.

And this configuration files need to be applied on each and every server. So probably the same configuration almost but slightly there are some few changes like maybe the host name is different a little bit like you want to use the same name host as server One and probably the server underscore. Maybe you want to just add a place let’s say City. Let’s say if it is in city A, probably server B in city B like that you want to add specific location to each and every name or maybe server one, server Two like that. Now these changes probably slightly there is a variation. So if you go and create a static file for each and every server, let’s say if I’m trying to make this configuration with the help of let’s say I’m using a static configuration for each server so I have five servers so I’m going to create a separate configuration file. That’s what we call this playbook here.

And probably separate configuration file for server two, separate configuration file for each and every server. That is not an efficient solution because that is going to make take a little bit more time because every new device you need to add the particular configuration file and multiple times you need to add. So this is where the templates are going to be useful. So normal technical normal term when you say template means it’s like a pre design kind of file where you made some changes according to your requirement and then you just distribute them to the multiple devices.

Now, same way here also we are going to use template. Now in the templates what we’ll be doing is we’ll be creating a configuration files with something called variables. Now this slight variation is called variables. The variables are referred to. So let’s say variable like here will be using YAML language and variable is containing the list of variables that will be substituting inside the template. Like I said, the example of server one, the server one should be the name should be Server but underscore and that should be the name of the location.

Like let’s say the hydra bar and this will be written in something like double extension where I’ll say location which means automatically this particular variable in each and every server it’s going to be the same. So just a copy paste of thing a template. But automatically inside this location is going to replace with the location like maybe Hyderabad, maybe Delhi or maybe Banglade, whatever the city name. This is just a general example what I’m using. So probably it can be anything like Ipirosing. You want to just replace the IP addressing. They all should start with 101, six, eight, one subnet and probably the variable will be like maybe you want to use 5051-5253 like that.

So these templates will be used using J two extension which is kind of Ginger two template engine which is being used. Now. This Ginger two template is actually used for enabling the dynamic expression inside which are replacing with variables. So it’s like whatever the variables which we are using which is going to substitute at the back end the engine name we call it as Ginger two templating engine. That’s the name used for that. And that’s the reason you’ll find this extension will be like dot j two extension. Like one more example I can say like you want to add a time in that particular config file and you can simply say now. There is something like now which means whatever the time, current time, that time should be included at that particular place, in that particular device.

So that is one more example. Like there is something called time now. And then you add curly presses. These pressures indicates that whatever you write inside this one will be a substitute value like replacing the variables. Like I said time now if you write it means it is going to replace with the current time the system time automatically replaced inside that individual file extensions. Now if you just want to see one sample file we can visit this URL. Probably here you can see this is the same URL what I’ll be using. And here you can see there are some preconfigured template files which are available on this website. Like there is something called voice and switch kind of thing. Initial commit.

If I click on this you’ll find this kind of template here. So whatever the values you see in the curly braces probably these are like the variables which are used which is going to replace automatically based on the specific values. Okay, so this is one kind of template file and if I go back you can also see one more template file.

• Category: Uncategorized