Cisco CCIE Security 350-701 – CHEF- Config MGMT Tool

1. CHEF- Config MGMT Tool

Next thing we’ll try to understand some of the basic concepts about the Chef. So we have seen the Puppet automation tool in the previous sections. So here we’ll try to see some of the concepts relevant to Chef. So when we talk about Chef it is more like a Puppet. So whatever the concepts we discussed in the Puppet, most of the concepts will apply so we don’t get into more details as we did in the ship, sorry, in the Puppet previous topics. So again, what is Chef? It is another automation tool we can say the config management tool we can say which is going to allow you to manage your configurations and an automation related task. Now it’s an open source. Again. Same like puppet. It is an open source and you can also have a paid enterprise version, same like Puppet. And this paid enterprise version will have a little bit more features when you compare with the free open source option.

Okay, so the same thing what we have seen in the Puppet as well and again, mainly this shape is designed to automate the configurations and the operations relevant to network and the server environment. So it can be any network related task or server related tasks like automating the virtual machines. Probably that is what server related network means. It can be automation of configurations related to routers features or any networking devices. Okay, so with the help of Chef we can configure and manage or maintain the company service and also we can integrate the cloud platforms.

You can also use this to integrate with the cloud platforms like we have Amazon or if you take any other Google where you can automatically deploy or automatically provision or configure your devices on the cloud as well. It is more ideal ship is more ideal automation automate configuration tool which is mainly for deploying or managing the cloud environment or storage environment, even the software deployments. So it’s kind of more ideally used in these scenarios. But it can also be used for network automation like automating your network or the server configurations. And again, as I said, it contains solutions, probably the ship. If you go to the website you will find the solutions for small and the large organizations and depending upon the type of solution you are looking, the requirement of the enterprise, the pricing and the features will vary.

So there are different versions in that available as well as per the requirements. Now, what is the language used to write the coding? The same like puppet. It uses Ruby language and it has its own domain specific language which is used inside the Ruby language. So probably this language is used to create the confirmation files. And this confirmation files, technically we call them as recipes. There’s a technical name in Puppet, we call it as manifest and recipes. And what is this confirmation files already we discussed it is a set of commands or the scripts you want to apply on the end devices or on the nodes. Now it uses pullmodel same like the previous Puppet software. In the case of pullmodel we already discussed the agent, the nodes will have an agent installed and that has to be initiated or whatever the configurations you have to do or whatever the feature you need to enable, you have to enable it. And then it is going to send out a request to the server.

Probably to the server we have something called Workstation. I’ll talk about this from where you can create the configuration files and then you can push them to the server and then it’s going to request the server to get the configuration files and the server is going to send out the configurations to apply onto the end nodes. So in the case of pull model, as we discussed, the agent is going to initiate the request and then the server is going to push down the or send down the configurations to the end nodes. So probably this process we have seen in detail in the previous Puppet topics. So in steps we have seen that option, push model, pull model.

Also we have seen in a separate video previously a little bit more details on how they differ. So it is more like a Puppet as I said, the way it manages or configure the servers or the way it uses the pull model, it’s the same thing. And also the master node architecture. You have the same master and the node architecture and also it supports open source and the paid version. So most of the features we have discussed, they are quite similar.

So whatever the concepts we discuss in the Puppet, most of the concepts will apply here as well. Of course there will be slight differences in the terminology, the structure. Now the structure is like how they define the Puppet configurations on the server, the state configurations probably because the way they write the script a little bit different, of course. And the terminology concepts will differ. Like in the case of Puppet, we call it as a manifest, that is a configuration file name. Here we call them as recipes. The modules we call them as models. Here we call them as cookbooks.

2. CHEF- Terminology

Okay. Now in this we’ll try to see some of the terminologies used inside the ship. Like most of the concepts, what we have seen in the Puppet, the same concept applies here. The only the naming wise, how they are named is different. Like starting with the first one, the shape server, the ship server is same. Like your puppet master. Now it’s a server. Exactly. You install the software where you have this Chef software running and from where you are going to manage the configurations. So you are going to do the config management and you’re going to push the configurations back to the end nodes. That is like the centralized server. And in Puppet terminology we call it as a Puppet Master. And in Chef terminology we call it as a Chef server. So you can compare that with the Puppet Master. The client is nothing but the Puppet agent, the end nodes.

Now these end notes which has the agent software installed on those clients or on those end devices. And in Chef technology we call it as a client. So you have this software installed and these agents will be managed by the server. And probably they are going to use the pull model where they are going to request the server to get the configuration. So the same concept applies. You need to have an agent software running on the end nodes. So in Puppet terminology we call it as a Puppet agent. Here we call it as a ship client. Next, there is something called recipe. Now, recipe is nothing but your configuration files. So on the server you are going to create the configuration files. And this configuration files includes the set of commands, what you want to apply on the specific nodes.

Like in terms of Cisco we can say like routing configurations or the ACL configurations or IP addressing. Or maybe if you’re using some server littered configurations, the virtual machine settings, probably those things present inside the configuration. And it is going to send this configuration file back to the nodes to apply the changes. So technically, in Chef we call it as recipe. And whereas the equivalent term used in the Puppet we have discussed in the Puppet topics previously called manifest. Likewise there is something called workstation. Now this is something new which is not present on the Puppet. Of course, in Puppet we call it as a Puppet console from where you enter the script.

But there is no separate device. It is inside your server itself. But whereas in the case of Chef, what we can do is we need to build the configurations, right? So probably in the Chef what we have to do is we have to build the configuration files. And these confirmation files need to be built, developed by the admin. And then later on you’re going to push this confirmation file back to the nodes. But what you can do is now these confirmation files can be built locally. On any of your machine. Like you can use your own laptop where some workstation software is installed and these configuration files can be built locally.

And then later on what you can do is you can push this configuration files to the server like upload, you can say we’ll upload this configuration files to the server and then the server is going to send it back to the nodes. So which means you don’t need to be physically present each and every time on the server to create this file. You can just build them on your own device and then later on you upload them to the server and then the server is going to send out send back to the nodes. So probably you can have a separate workstation, this can be your own laptop where you’ll be building those scripts and then you are uploading them to the server. So that is a kind of additional thing what you have in the shell. But whereas in the Puppet you don’t have this option, of course you have to do it on the server itself and that is what we call a puppet console terminal inside the server.

But whereas this workstation is kind of separate concept or a separate device, it can be a separate device where you can build those scripts and then upload them to the server. And then finally there is something called cookbook. Now cookbook you can compare this with a model, puppet model. Like the cookbook is a collection of recipes, collection of all your recipes, means configuration files here, configuration files and then inside that there will be a lot of options like variables, whatever all those things include in that. So there will be a separate cookbook for each and every vendor. Like there will be a separate set of configurations for NX operating system and there will be separate for iOS XE like that every vendor or every type of device there will be a separate set of configurations, maybe separate, separate tasks.

There will be separate set of files used and technically we call them as cookbook. Like this is an example again, if you remember previously I discussed SQL based options like SQL based cookbook you can use for SQL devices, cisco based cookbook for Cisco devices in that you can have different operating system. So probably if you try to see the terminology wise the names will change but the roles are the same. So technically what they do is the same thing whether you’re using the Puppet software or if you’re using the Chef tool, the naming and the terminology is will differ. Now here you can see there is a simple configuration file relevant to Chef.

Like you can see here, this is one example I got a couple of separate config files. Now this is kind of creating one loopback interface with an IP address where I want this configuration to be applied onto the end node. And here I am doing some kind of Beijingp related configurations. So if you see the command hierarchy is more similar to how you do in the devices, I think this is more specific on XR router, how the configuration goes.

And then here you can see this is one sample example how to create an OSP of protocol. And then apply some changes here, like changing the timers of the OSP of LSS and applying the cost values, and then changing the advertising the OSP of and changing the cost values, and then applying some authentication commands. Here you can see these are all authentication related commands. So the format, the way it looks, it’s different because Chef uses a different kind of scripting. Of course, it uses the same Ruby language, but they’ll be a domain specific language used inside.

• Category: Uncategorized