So, hey guys, we are recording this session. The last time we were working on a exercise, we actually introduced this idea of, what was that thing called? Infrastructure as code, right? So we were working on this idea where we began discussing DevOps a little bit, and then we switched over to understanding infrastructure as code. We discussed a bunch of these products that are available, how they operate conceptually, and then we jumped into an exercise. That exercise was this one, for which I think I need to log in. So I will log in. And let me log in, come on. Yeah, so logged in, and now we ran that exercise. And I think some of you have actually done this exercise yourself also. I just want to remind everybody that I want you to do this exercise strictly inside your virtual machine. Don't bother doing it outside. If you do it outside, it might work halfway through, and actually mess up your laptop. So don't bother, don't mess up. There's no benefit of messing up your beautifully constructed machine. And so what happens is, if you really think about what's going on, if you look at that folder here, what was using Chef Solo, which is what we cloned from some location here on that location here. That's what we did. And when we clone it, it brings down a bunch of things, and then it installs Apache software effectively. And so you don't want Apache running on your laptop. There is no reason for you to run Apache. So that's why I don't recommend running this on your laptop until you fully get comfortable with the tools as to how they actually operate. And at that stage, totally fine. Do whatever you like. But first, get comfortable with what are these things doing? What's it doing to the machine? You need to really, really understand that detail before you venture out using the software on your own personal computers. There is no benefit to doing that right away. That's why I say that stick to the VM. So in that project, we have it cloned here, and we saw that we edited it a little bit. We modified it also. We did also the homework. We also did the homework right on the fly almost at the end of the last session. And the homework assignment, I have written it down in Slack chat, as well as in our... What is that? Project work in the last item here. I think that's where I have been collecting the homework. So the homework for the extension of this exercise was to modify this package. It was installing Apache all over the place. And so we modified this exercise to run nginx instead of Apache. And that modification homework, we already finished that in the last session. It is, by the way, the solution to that homework is written down here in that location. You can see it. I will be pasting a link for that solution to the homework in our Slack chat so that you have access to that. Also, as you go along, do it. Some of you are asking for more time for homework, and I would like to let everybody know that it is totally fine to take your time. I mean, there's no hurry as such. I think people are struggling with the snow and the work and family and things. So take your time. There is no rush. There is no hurry. Only goal that I have is that you want to benefit from this thing. That's the primary goal. So make use of it the way you want. Make use of these things and apply that to what you work, that you do in your company, in your business. That's my goal, is to make sure that you can actually use these open source products and new technologies and put them back to work in your business. That's the idea behind this bootcamp. So I have, I think, pasted that link in the homework assignment, and I'll now briefly recap the actual exercise we did the other day, which is this using Chef Solo. It is the very first time we ran Chef Solo, and so we would like to understand now what is Chef and what does Chef call Chef Solo? What is the difference between the other Chef, like this is a Chef Solo implementation and run. There was a reference about SoloRB and Chef Solo, and we just ran Chef without actually discussing the details behind what Chef is, what are the variations of it, because we wanted to get to a quick implementation so we can really get to work, get to understand what it can do for us. So here is our notepad coming up, but I will now describe the idea, the differences between, there are two different types of implementation of Chef available. I'd like to discuss both of them so that you will understand where to use what, or how are they different from each other. So here are the two. On one end, we use the word Solo, and that was the Chef Solo product that we used. It is open source. The other product is very, very similar to this product, and it is called Chef, or another, the full name is Chef, and there are two parts to it. One of them is called Chef Client, and the related part is called Chef Server. Chef Server, and these are also open source. Now you will wonder, how does the company Chef make money? There's a company called chef.io. How do they make money? Well, these are open source products, and they're free, as in freedom, and also free as in $0. So they are open, so the company makes money from providing services to other companies that want to use these products. That's the primary business model. It is very similar to the concept of the Red Hat company, which makes Red Hat Linux, which is open source. But then this Red Hat company, which recently got acquired by IBM, is a multi-billion dollar company just on providing services to businesses trying to use Linux. So it's a services model. That's how they make money, on providing services to use these things. In fact, most of their services are actually focused on these two products, because this is less popular, so much so that people don't even mention it. In fact, if you go to the Chef company website, there is no reference of this thing. If you go to GitHub, you will of course find it. You will find this as well as this, all these three things you will find. Now, the name Chef Solo basically means that it works alone, on its own, and it doesn't need a component like this. So it just works alone with nothing else. It works on its own. But as this guy, the Chef client software needs a Chef server software to go along. That's the top level summary. Now, if you go into deeper, the Chef Solo is a client-side binary. Client-side binary, and this is Chef client, is also a client-side binary. In fact, those two binaries are virtually similar. They are very, very similar in its nature, as you can see in source code. They are very, very similar in the way they operate, except that this one expects that there is a Chef server available that it can talk to, and it can receive some information about what needs to happen on the client-side so that it can do the work. So this work, like doing the work, meaning implementing scenarios, meaning running cookbooks, meaning running whatever your desire is. So you have to have a desire, and you will implement that desire in form of a design, and the design is written down in basically a Git repository that specifies your intention or your ultimate design, or I call it desired state configuration. So you specify what you want, and you write that down in a repository, in a Git repo. And then you run this software so it will do the work. Same thing with this guy. You have to have your desired state configuration written down in a Git repository, and then you ask this client-side software to do the work, and it will do what you desire, this desire. It will implement your desire. Now, typically what you will know is that when you want to run this tool like Chef or any other tool, they all operate basically the same way, is that they will actually run on some machine in the cloud. So here is machine number one, here is machine number 32, here is machine number 45, like that. They will be running here and here and here, and implementing your desired state configuration. Whatever you desire, you write that down in a Git repository. These tools, whether it is Chef Solo or whether it is a Chef client, they're very similar in nature. They operate and work on these machines here. They need to run there in order for them to implement your desire. This implementation needs to happen on these target machines. These target machines are in the cloud somewhere. So they need to receive that desire from you. You need to provide this to the client, to Chef Solo, to Chef client. They need to know what you intend, your intentions or your desire that need to be provided to this software. How did we provide our intention to the software? We gave them, we actually ran it in a Git repository directly. That's how Chef Solo was able to receive the desire. That's the scenario how Chef Solo works. Now, how do you give your desire or your intention or your design or your DSC? How do you provide that to the Chef client software? Well, you don't directly go like that, but instead, you provide it through a server. And you put your, whatever you want, your desired state configuration in the server and you store it here. So you store it here. Whatever your intentions are, your desire is, you put that in the server. And then you basically go on vacation at that time, because what Chef client will do is it will also run on. Let me just change my screen. So here, there's a cloud, there is a machine here, there's a machine here, there are more machines like that, and you want your desire to be implemented. So Chef needs to run here. And so these are Chef clients, client, client. They need to run on those machines. But again, it needs to know what you intended. So you are on vacation in Hawaii, and so you cannot be reached, you're out of reach. So you need to keep your intention, your desired state configuration needs to be stored in a central location. And that central location can be a Chef server. That's where you put your intentions, your desire, your great ideas that you have, and you just put it here. And then you go to Hawaii. Now these machines will become whatever you intend them to become when you run Chef client, because client knows how to go to the Chef server and then get your desire. This client will know how to reach the Chef server and then get your desire. And same with this guy. They will reach out to the Chef server and get your desire. Whatever DSC that you have, desired state configuration, they'll just grab it from your central location, which in this example could be, and I'm saying could be Chef server. In another scenario, you can also implement something like a bucket and put your desired state configuration in here. And you go to Hawaii, and you can have Chef solo. Also grab your, basically download your configuration from a bucket like S3 bucket, and then run it on machines, whatever you have here or here, more machines, more machines running Chef solo. That works out very, very similarly. Whether you use solo and just plain old, some folder sitting in some location, or you use a structure like Chef server, like here. And then that Chef server provides your DSC, or desired state configuration to the machine so that the client will run on the machine. Now, a quick recap on what the first exercise we did. We had our virtual machine here, the Cloud Genius Workstation. And we ran our Chef solo right here. And we ran that in a repository. So it knew what to obtain from it, running right there, it knows the desire, the desired state configuration already knows. And it was targeting right this machine here. This is the machine, this one. So we did not even use a cloud at all. But any subsequent exercises we'll be doing will actually not target this machine, will target that machine somewhere in the cloud. Some machine or some bunch of machines like that. So we will have to operate remotely. We'll still work here, and we'll execute commands here that will basically instantiate things out in the cloud. So it will create stuff over there, and do whatever you want to do, make things happen out of it in the cloud, as opposed to you running it right here. That's the difference going to be going forward. That's the dominant usage. So we want to have some cloud here, another cloud here, and another here, and like that. And you are sitting here in your office with your laptop, and you want to run some tool here, some tool. And that tool will remotely invoke the cloud. This is cloud number one, this is cloud number two, and this is another cloud. So it needs to know how to interface with this cloud company, and then start a machine from scratch, like fresh bare bones, fresh new machine. It knows how to start one. It knows how to then instantiate a tool to run here. And this tool will know how to get your desired state configuration from a central Chef server, or it could be some Ansible tower solution, or some other centralized solution where you keep your desired state configuration. And that configuration is provided to the tool, and you need to have some remote execution tool that will execute remotely on the target cloud. This cloud, that cloud, that cloud, and will make things happen for you. So you sit here in your office, somewhere, in some location. You don't need to be in some building where the cloud is. You can be away from there. You remotely execute some tool. We'll talk about those tools, we actually use them. But I'm just giving you a structure as to how things are going to operate, and in general, how you actually handle the scenarios. So from a usage perspective, you need to be very clear about what you want in your desire. You need to write that down in a repository, and keep it in Git. And if you're using Chef server, you need to know where the Chef server is, and you need to upload your stuff into the Chef server. And then you invoke using a remote execution tool, remote exec, and you will use a tool to remotely execute your desire here in some cloud. It will instantiate new machines, run Chef client. It will know to go to the Chef server and bring your desire, and here, and then implement it. And then this will become whatever you want it to become, and that you wrote down here, and that you uploaded here. So it knows what you want, and this magic will happen in your cloud when you remotely execute some execution command. For example, if you're using Chef, it will be the Knife command. So you instantiate the Knife command, which will essentially do the magic for you, make the magic happen. So you're basically remote executing Chef using Knife as a tool, and you will remember and recall that the word Chef is basically a cooking-related phrase. Cooking-related phrase. So all the things that Chef will use will be related to something to do with cooking. For example, this tool called Knife, of course, in the kitchen. This DSC that I keep referring to, or sometimes I call it a gate repository, there are various names for the same thing, and the names can be Kitchen, or Repo, or Chef Repo, or DSC, or basically whatever you intend. So these are your intentions, what you want to make things happen, and you keep track of your intention in a gate repository with a great amount of discipline, so exactly know what you need to happen in the cloud, and you basically maintain it very carefully, and you upload it to the Chef server, and then the rest of the magic happens automatically. All your ideas that you have, you need to be writing them down in this gate repository very, very carefully, and of course, testing it thoroughly, and then it will run your intentions, your desires in a cloud of your choice, and maintain it for you also. So that's the thing that we will see now. Now we have our next exercise. By the way, the whole segment here on Chef, and Ansible, and Docker, and Kubernetes, it's completely hands-on. So there is, basically in here, you will find it's going to be a series of exercises after one after the other, non-stop back-to-back. And one more cautionary word here is that these exercises build on top of each other, especially the Chef portions. They are an incremental building on top of each other exercises, which means if you skip one, that'll be very difficult for you to understand what's going on in the next one. That's why, especially this section that I'm going to begin is going to actually be describing concepts underneath this tooling that I'm talking about, which will help you understand without reading the documentation. And that's the good part. Of course, there is Chef documentation. You can read that. And you can, of course, read the documentation and do the business of understanding a tool and using it like everybody else does. But in our exercise, which I'm going to start today, which is this one, which I'm going to grab a link and give it to you in Slack chat so you have it handy. And you can probably do it along with me as I go. So here is the link, and it's coming up, and there it is. And that is, again, focusing on using Chef Solo right now. And that doesn't require us to use a Chef server. So we will, first of all, use Chef Solo to understand how Chef works, understand each and every component inside it. And then when we get a good feel of it, then we can switch over to using a Chef server. We'll understand we'll have another set of exercises that will use Chef client and Chef server and use the Knife execution tool also. And that's the coming steps. But before we get into that, I want to make sure that we are understanding what does Chef do for us from its detailed perspective. And the best way to do that is just by doing running small, simple exercises. So we understand what things are in the context of using this particular tool. There are other ways of handling the same scenario, which is just to go to documentation, chef.io doc, and read it here. That's another possibility. You can totally do that if you like. In fact, that is the official way of doing things. So there are various ways you will see that I will do that are somewhat different than what other people do. And that is because that's how open source is. You know, it is how you want it to be is how you can modify it and do it. So the way I use Chef can be actually different than how other people use Chef. And would be different than how you would use Chef in your practice. So things will be different. And that's how it goes in open source. There is no right way or wrong way. You know, it is just the way that works for you is the correct way for you. And so what I'm going to describe you, describe to you in the next subsequent steps, may be different from the official Chef documentation that you can read here. And you can read and follow along. By the way, this is also good documentation. Absolutely brilliant. Very nicely written. But I'm not following that one. Just so you know, it is there for you. It is openly available and it is on GitHub. What I am following is this sequence, which is using Chef solo in solo mode. And so we'll begin understanding concepts. And we'll do that with simple exercises. So we will now begin the first exercise, which is you want to lay out the foundation for a kitchen. Yes, kitchen, that's the name. So kitchen is basically this folder like I have here, like this ready-made folder that I had here using Chef solo, that folder, which I don't intend to use anymore, but I have it here. That was a kitchen. We are going to create a new kitchen for us ourselves for a fresh project. So we'll not use this one. So we'll come out of it, leave it alone. And we'll begin initializing a new one for ourselves right now, right here. And what I will do is just follow along these steps. So prepare the kitchen foundation. What are we really doing is creating a folder, honestly. And so we'll create one. We'll call it My Cloud, like this. So if you see that my font is too small, please ask me to change the font size. I can adjust it. Same with the right and the left side. If you see that the browser window is too small, I can make it big. Just let me know. If the font is too small or too big, please ask me to adjust so you can see it properly. So right now I think the font is okay, but you need to tell me. So I am going to create a folder called Cloud and then go inside it. That's it, that's simple as that. So that's going to be the place where I will create my kitchen. Right now it is empty, that is expected. Now in that kitchen, what I want to do is to establish the very first thing, is a very strong sense of discipline. I need to know what I'm going to do. I need to know what I need from my application. I will need to write that down in a structured fashion and call out, I need these things, that version number, this thing, that version number. And you may recall that we have done such a thing before. We have done this thing called a gem file. We have used it before, which is basically a list. A gem file is basically a list of things that I need in a structured, disciplined fashion. And that helps us run things in a very predictable manner, as opposed to you work on a different version and I work on something different. I don't want these things to happen in a project. So what I would like to do is the entire team should stick to a generally agreed upon set of versions so that everybody operates on the same set of things. Otherwise, if I am working on some version of say 050, as opposed to 060, Knife Solo, then it might work for me and not work for you and that's a mismatch. We don't want these things to happen. So you want to bring the whole team on a given project to be working on the same set of dependencies. That discipline comes from this folder, which is what I'm creating now. And this file will regulate that behavior, especially when you're talking about Ruby language, that's the way to regulate discipline. If you're talking about other languages, they have their own methods. Like Python will have a file called requirements.txt. This one, Ruby language has a file called gem file. JavaScript has a file called package.json. So every language has to have such a discipline method to regulate a dependency map. Like what do I need in my project? So that's what I'm beginning to create a file here called gem file with a capital G. So I'll open up my atom editor in an empty folder. So here it comes. And there I have nothing, which is exactly what I expect. So I'm going to create a new file and call it capital G-E-M-F-I-L-E. That file will contain all the things that I need. And this is what I think I want. So I'm going to copy that. And dump it here. And so now I have it, I save it. So that is my gem file. What I need to do is make sure that my applications that I'm going to run in this kitchen or chef repo or desired state configuration, whatever you call it, it is basically that folder I'm talking about. This folder has been given a list of things it needs. And so you need to get those things and you need to get those from where? From this source location here. Now, if you are in a company that doesn't allow you to go to random places to download random software, like your company, for example, you will probably not be allowed to go to this random website, which is by the way, a very beautiful website, nothing wrong with that. But it's just your company policy that doesn't allow you to go download random software. So how do you handle that situation where your company says, you should not be installing random third party software like this from some Rubygen.org, we don't approve it. And so that happens, what do you do? That's a very first question most people ask, especially from your company like Boeing, you know, it doesn't allow random third party software, which is a very good thing, by the way. And it is a right thing to do. So you should not allow people in your company to just download whatever they want and play with it. And maybe it has something bad, you don't know. So you want to regulate that right at the very beginning. So how do you handle those things? You handle it by changing the source and regulating it internally in your company. Now, I'm just making a fictitious example right now, but you will do it like this. You will say, our Ruby software that we have approved will be stored in this location, like that. And you just call it your location. So any gems that will be downloaded will come from internal sources, that website, rubygems.boeing.com is one example. I'm just making it up right now, but giving you an idea that this is something that you should be able to do. And inside that website that you need to create and maintain will actually contain the approved versions of correct approved versions of appropriate gems or Ruby packages that you may have, or you may want to be used within your company. That way you can regulate the behavior of your employees. And that's the recommended approach. Now, that is a fictitious soft fictitious website, by the way, I just made it up. So I'm going to go back to what it was like this. So that is a valid website. rubygems.org is a valid website. You can go there and find that it will give you a list of gems that you can get. So, but I don't want to go to this website and download one gem at a time. For example, the Chef is also a gem right there. So I don't want to download each and every item manually. So what I want to do is have a systematic method to grab these gems and make them available to me here. And that method of download is called bundle. Bundle is an action or basically an executable that comes as a part of the bundler gem. Bundler is a gem, bundle is the action. And what bundle does is looks at this gem file, which we have here. And it will go to the source location wherever it is and download all the gems which are mentioned at the version numbers that match and then install them. So that's what we want to do. We want to actually go and install the bundle action. So what bundle does is go to that location, the source location mentioned in the gem file and download all the things inside. So beginning from the first line. That's what you will see happen right now when I say bundle install. It will go to Ruby gems, download these four things, install them and report success. And here it is happening and it almost finishes. So finishing up pretty soon. And that's what we did. So we have now the things that we wanted in our team for this particular project. We are installing them, we have it now. Beautiful. Now what? So we have the dependencies loaded, but let us see what we can do next with it. And how do we actually use these things together? And so what I'm going to do now is, yeah, that's an Armaguard. If you know what this thing is, you probably understand. When I first heard of it, I did not understand, but now I do. And so this Armaguard is a thing that I'll discuss just briefly. But before we get there, what we have done up until now is that we have a list of gems already installed, which means one of the gems was chef. And here is the version 12, 10, 24. If I say gem list and then look for the chef gem, what do I get? I have two versions of chef here. I have 12, 21, 14, and I have 12, 10, 24. So what do I do? And that might happen. And that's a good thing that it happened because I think it'll help me illustrate another point, which is very important. The point is that I want my team to use this version, which I have installed here. And if the font size is too small, please tell me. I'll edit it and magnify it. I have 12, 10, 24 that I wanted, and I have it. And I have this one also, which I don't necessarily want for this project. Maybe I want it for another project, but not for this. For this, I want 10, 12, 10, 24. That's what I want. Now the problem that I have right now, if I say chef and then the client version of chef, or just say chef and then dash V, find the version. Oh, sorry, not this, not this. So I need to say chef client dash V. Yeah, I see it. But it is the wrong version running, and I don't want that to happen. I want the version I want that one to run. But at the same time, I don't want to remove this version because other projects might require it. This project, the cloud project that I'm working on with this gem file, it wants 12, 10, 24. But when I invoke chef client, for example, chef client again, it runs 12, 21, 14, and never runs this version, which is going to be a problem. So how do I then make sure that in this directory, in this folder, in this project, whenever I run chef client, it always executes 12, 10, 24. How do I force this discipline and not randomly run something else, some other version, like it is currently running 12, 21, 14, which is not what I want. I want to run the one version I want, which is I mentioned here, that's the one I want. So there is a way to do that. There is a way to enforce discipline to execution of gems. And that discipline comes from bundle exec prefix. Here's how it goes. Bundle exec is the prefix you want to apply to any command execution, like that. And then whatever you want to do afterwards. So that's the prefix that you apply, meaning any command you want to run, before that you put bundle exec. And now you run the same command like before. And you will find that it actually looks at the gem file in the current folder and follows the discipline provided by the gem file dictated by the gem file here. So that's what you will see is that version executes, not this, we don't want that in this project. We want that one. So that's what you will receive. And there it is, 12, 10, 24. And that's how you should execute every command for a project that requires discipline. You need to know exactly which version of a particular software runs. You need to execute that under the control of bundle exec prefix. And then it will look at the gem file in that folder and follow whatever you dictate. And your dictates is right there. That's what you said that you want. So it will use exactly that version, 12, 10, 24. So that's the concept, which I think I was lucky to get that scenario implement. It just so happened that I have two versions of Chef installed. So I was able to illustrate that point. Having said, if you're just doing one project in your life, you can actually get rid of the 12, 21, 14, but you don't need to, because there is no such thing as only one project in your life. You will have multiple projects in the same computer for one person at the same time. It might happen so, many times it happens that you dictate that I want this version for that project and that version for the other project. And you can control that very, very simply by prefixing like this, bundle exec. So having discussed this piece, let's go forward with the other ideas. Like the other idea is that just like in our first example that I ran, which was using Chef Solo, we were able to go to this thing called Supermarket. And there we were able to find the Apache 2 cookbook, and which was by the way, already there in the kitchen, in the Chef repo, in the desired state configuration. We already had that cookbook to begin with, because I gave it to you. But then we wanted to find Nginx. So we went there and we found this cookbook. And we find that this cookbook was downloadable. So I downloaded it and I used it. But then this business of using a mouse and then going to a browser and downloading stuff is manual and boring. So I don't want to do it this way at all. In fact, you will see that I wanted to get the Ruby gems that I want. And so I have the Chef gem, but I did not go there to download it. But I obtained the gem through a systematic method. That method was using a gem file, which has this construct. So here's this gem file that I wrote down whatever versions I need. And then I said, bundler, please go get me those things that I want. I want you to get me those things. So what did we do? We said bundle install. And what bundle install did, is it looked at this source and these version numbers and say, okay, let me go to the source, which is the Ruby gems website and then install it. So we have it now. I did not go there and download one at a time, which is kind of boring. I don't want to do that. And so when it installs, then it creates this file here called gem file.lock. And that lock basically is a gigantic map of cross-dependency between various gems that are interdependent among each other. And that meets the condition that we have laid out in our gem file. So this lock file basically contains an interdependency map of all the related gems and how are they interconnected with each other, which exact version numbers called out. You can actually read that once you receive a gem file lock after you run bundler software. And this file will automatically get created. If you somehow manage to delete it, it's not a big deal at all because you have to have the gem file in place. And then all you need to do is say bundle install, and it will quickly create that file. It'll go look at the Ruby gems and find the gems, download it, install it. You already have it, so it's done. And here it goes, the lock file gets created. That's the idea behind the lock file and the gem file. So the role of gem file was to go to Ruby gems website here and then grab the gems and install it. And so the source was Ruby gems and the file was gem file. And the tool we used was bundler, which is also a gem and we have it. So we used it and the action was bundle. Very, very similar to this idea is the new idea that I'm going to talk about now. And that idea is to deal with cookbooks. The cookbooks are available in supermarket. You know that they are here. For example, NGINX, you can download them here manually, which I don't want, but I just did accidentally. So that's not how I want to actually get my books. So, but I still want to go to that website and grab the books, but in an automatic fashion. So what I will do is create a file just like gem file, another file and call it books file. And that's a funny name. And there is a funny reason behind that funny name. So I'll tell you the reason also. The reason is that, you know, when this thing, the meaning behind the word I just wrote is called bookshelf. And if you say that out loud like this, bookshelf, it means bookshelf. So if you want to create a new product today and call it for cookbook management, I need to have a tool called bookshelf where I can keep my books. So if you create a name like bookshelf, that's a bad idea in general for a new product, because if you go and search Google for bookshelf, what do you find? I don't know what you will find, but let's go see. You'll find bookshelf. I mean, that's not what you want to happen for your new product. So you go to Google and then you say bookshelf. What do you see? You see these things, right? I don't want that. So how do I keep the name bookshelf, but twist the spelling just a little bit. So it sounds like bookshelf, but it is not that spelling. So that's the reason why some smart people that created bookshelf renamed it like this. Berkshelf. And therefore this meme comes along. Omagar Berkshelf. Honestly, I did not understand memes, but now I do. And so at least this meme, so Berkshelf. So if you search Berkshelf, I bet you money it will be the very first link. And there it is. It goes straight to Berkshelf.com, and Berkshelf is an open source cookbook manager. There it is. So what this will do is that, you know, to look at a file called Berksfile. Omg, yeah, Armagard is omg. You're right, Armagard, that is omg. And so, well, you probably knew that already. I did not know first time when I read the Armagard thing, because I come from a different culture, but I think I, you know, 20 years, and so I understand these things now. So this Berkshelf that I'm talking about right now is basically a tool that will help us do very, very similar things like what this tool did for us. This BerkBundler tool. Let me just grab my pen and I'll write these things here. So what Berkshelf does is looks at this file called Berksfile, and that Berksfile will be a list with version numbers of names and versions and names and versions like that. And it'll look at that list and go to supermarket here, whatever this site is. And then, you know, basically download the cookbooks. And put that in a specific location for you as you need. So that's the idea. So now we will play this in action for real. So I'm going to erase this and fill up my Berksfile. It's not a books file, it's Berksfile. And so I'm going to close it, it is currently empty. And I will go and look at our instructions. So see what we have in the instruction, because I can always, I tend to deviate from the written instructions because I don't need to follow them. Sometimes, you know, go my own way, but that happens. And that happens, you know, people find it hard to actually keep track of what I'm doing versus what is written down here. So I would rather not deviate. That's why I can basically do without the website, but then that doesn't work. People want to match what is written on the website with what I am doing for live. And that's why I usually go and read. So I don't deviate much from what is written down here, which helps people apparently. Otherwise, when this site did not exist, I used to just run the course without having a website. And just on videos live, purely live, just out of thin air, I'll come up with ideas and just do it. But now that we have the website, let's follow it. That's the whole idea. So I briefly discussed with you about this thing called works shelf. And now I will use it. The way you use that is to instantiate a kitchen. So that's the underlying idea. We have the folder here containing a gem file and a burqs file, which I just wanted to show you and give you an example for. So I'm going to delete that empty burq file because that's not necessary right now. All we have in this current folder called cloud is just a gem file. But in that gem file, you will notice that I have installed a gem, which is the burq shelf gem. So now I want to use that gem. And using that gem, I want to convert this folder into a proper kitchen. And a proper kitchen will have whatever you think, utensils and cooktop and all that. So I'm just kidding. That's what we are creating, converting this folder into a kitchen, into a repo, into a chef repo, into whatever names you want to use. Basically, adding a bunch of things here so that it becomes usable by chef. That's the idea behind creating a kitchen. And we'll use this tool to create. So that's what we are actually going to use right now. So what we'll do is we'll use the, by the way, there are a couple other things here. So let me see, let me read the instructions here. OK. OK, got it. So we also have the chef gem. And this related gems, we have these two. So there's a knife solo gem. There is a rack gem, which are required by the other two. So primarily, what we wanted is the chef gem installed and the workshop gem installed. So those two are available to us. And now we will be using them to instantiate a kitchen in this folder. And the way that instantiation happens is with a knife tool, which is a part of your chef product. Knife is a remote execution tool. A bunch of other things it does for us. We'll use that tool, which comes along as a part of the chef gem. Use this knife tool to instantiate a new kitchen here. That's the plan mentioned in this location here. And so we'll execute that now. How do we execute? We simply say bundle exec, which is the prefix we need. Anything we'll do is bundle exec, which is just to enforce discipline. And then in there, knife solo, meaning I'm going to use the knife solo version right now, not using chef server right away. And I want to initialize a kitchen right here with a dot. The dot here indicates this location. Please make me a kitchen right here. So initialize a kitchen using the knife tool for use with chef solo right here with a dot. And bundle exec prefix. So what this will do is fill up my folder cloud with a bunch of things, a bunch of empty things with nothing in it. Basically, it is nothingness. It's a whole lot of nothingness you will see coming. It's empty. And so you see lots of things happen. And as a result, you will see lots of files created. And almost all these files are empty. All the folders are empty because it doesn't know what to do. But it has some of the ideas that we need for us to use this folder, for us to use chef, specifically chef solo in this example. We know what gemfile is, and we know what gemfile lock is. So those two files we understand. But all other files and folders are empty. Let's begin with the bottom up. So we have the next file here, Burke's file, which is also empty, almost empty. There's a source location here, which we need to change. We need to say, you know what, you should go to the supermarket. And so we'll change it. We'll say, not this location, but please go to the supermarket to grab the books, burks, I should say. Grab the cook burks, go to the supermarket. Not here. So we'll delete that later on. So that's that burk file. We'll have this file called gitignore. We'll talk about gitignore also later. We have a folder called site cookbooks, which is empty. We have a folder called, by the way, that file is empty file. And we'll talk about that empty files. And what do they mean? The file is called.gitkeep. This file called.gitignore, that will do with something to do with git. We'll talk about git files later. Let's go first focus on the concepts here. The roles folder is also empty, with an empty file called.gitkeep. Nodes folder is empty. Environments, empty. Data bags, empty. Cookbook, empty. Cookbooks, empty. And then this folder is not empty. Let's go see that. This folder contains a useful file. It is probably the only useful file we have right now in this entire creation, and is also the most important file in Chef. That file is knife.rb. This file contains some of the details that we need to know. We need Chef to know about what do we intend to do. Where are things? Like the other example, we had solo.rb. And solo.rb told, where are my cookbooks, and where is my DNA injection? The same ideas here, slightly expanded. It describes where are things in the project. That's this definition file. This is the most important file, and its name is.chef. This folder name is.chef, which means it is supposed to be hidden. And so it is supposed to be hidden, meaning it is going to contain secret information. So we'll store our secret information here in this file. And I want you to not share this detail that you will keep with other people, because it doesn't make sense. That's where the secrets go, right? Amazon secret, and Digital Ocean secret, and Google secret, and Microsoft secret. All the secrets, you will need to store them here in this file. And of course, save it, and do not share outside your team, only within your team, so you know you keep control of your secrets carefully, because your credit card is tied with it. So don't share this particular file with other people. Having said, that's the most important file, which contains details. And we'll pay attention to it quite a bit as we go along. So we just stocked our kitchen with a bunch of nothing things, empty things, basically. And now we have to move forward with actually using this kitchen, basically fill it up, fill it up with useful stuff. So we have in our folder, we discussed briefly this file called KnifeRB, which you're looking at. And that contains how Chef will work. We'll discuss that in greater depth as we go along. This cookbook folder that you're looking at here, which is empty currently, is the place where you will need to store cookbooks. And I said, you will need to store. The word you is actually wrong, because it's Berkshelf or other tools. We'll go to supermarket and grab the books and put them here in that folder, right there, for you. So you don't have to do it. When you need the cookbook, when you want to use it, it will magically appear here, automatically. So you don't have to worry about that folder at all. In fact, I suggest that don't touch it. Don't mess with it. You're not creating new cookbooks right now. You are using cookbooks available in the supermarket. So don't mess with it, honestly. You can go and look. Nothing prevents you from doing that, but don't mess with it. Next one is the idea called site cookbooks. So another folder here, which is very similar to this folder, cookbooks. And so here, you will store cookbooks from supermarket. And here, you will store cookbooks you create. And this may be something that you want to keep secret. You don't want to give it to the world outside. Maybe you want to create your own, and you write your own software, and you put that here. And that is what we will be doing in a subsequent exercise, create our own cookbooks, and put them here. These are your cookbooks. These are community cookbooks provided to you by the supermarket. That's where you will keep them here. And whatever your things are, you need to put them here. Now here, you will see that in our cookbook path, the sequence here, cookbooks first and site cookbooks later, that sequence needs to be edited in that the priority should be given to your work. Whatever you create needs to get priority over and above these things. And so this priority can be adjusted by simply moving this here and this one here. Just give first preference to this, then here. That priority switch has to happen. We'll be doing that later on. Not right away, but maybe in the next 10 minutes. And so clearing this ink right now and just staying focused on the idea that I briefly mentioned, this sequence that you're looking at here, this needs to be here. So that this folder gets priority over and above the cookbooks provided to you from the community. You want to change something, make something new. And so maybe this one takes over, which is a bad idea. So you don't want to give that precedence. You want to give precedence to this guy, your creation. So you know what you're dealing with. And that's the reason why you need to switch. We'll do that, switch later. Next. Next idea is, so the next key idea is right here. It is the idea of data bags. And these are a place to store data, basically. A place to store data. And what data are we talking about? We're talking about usernames, passwords, API credentials, API key, other secrets that relate to execution. So runtime execution of something needs some secret. Well, that data needs to be stored in there. Now, that folder has to have a structural hierarchy. And I'll tell you what that means. It basically means like this. It means that you will have, in the bags folder, there will be a bag, which is going to be a folder. So in that folder, there will be items in the bag. And then there will be more bags. And the bag will have items. And then there will be more bags. Like that. And these bags can have items. And that's how the structure is. So these bags will sit in the bags folder. And items will be inside a bag. And these items are basically plain text files. Everything we do in Chef, or basically just about everything that I do, is all plain text. And so we use atom or tools like that to basically deal with plain and simple files that you can read, like humans can read, directly. And we'll store stuff in the plain text files, create them here, put them here, and then put that file here. And then Chef will know how to handle it. Because it is actually human readable. The entire course is completely plain text files. There is no need to use complicated software. Simple VI or Nano will work just fine, or even atom will work just fine. Having said, this is the idea where we keep items of secrecy, like passwords, or API keys, or other data related to runtime execution. And that data needs to be stored in a data bag. That's the idea. That's the purpose behind that folder. Next idea, environments. This idea of environment has to do with how you want to use and segregate your actual work. Maybe you want to have certain machines belong to the production environment. And this machine is a test machine. And these machines are staging machines. And so you want to have a staging machine. So you'll put that machine in the staging environment and this machine for testing. And these two machines are in actual production. So you classify your machines according to how you want them to be correctly tagged for a given environment. And that's where you define it here. Again, in plain text files. Or you will see them when it comes. It's not a big deal. You just define what you want. These machines should go in that environment. These machines should be in that environment. So the environmental definitions, they will go in that folder. Next idea, nodes. And so what are nodes in the context of Chef? They are machines. I keep mentioning about you have a cloud and then you have the machine here, 37. And you want to target that machine. And Chef will run there. And so when Chef runs here, that machine is called a node in Chef language. Nothing different as such. It's just a computer. That's a node. So every node you want to handle, there has to be an entry here in that folder. That's the idea behind a machine that you want to target so that Chef knows where to go to what. That's the concept behind nodes under management of Chef. So Chef will manage these nodes or the machines. And then you will have your desire implemented. Next idea is another way to classify your machines. That idea is roles. This idea is basically how you classify. Again, you have machines here and more machines and like that. And you want to say that all these machines, all of them needs to be up to date, updated. They all need to have Git software. They all need to have my favorite software, Vi, which I don't know how many of you use. But maybe some of you actually use. And others never even heard of it. This thing is called Vi, which is, if you ask me how to operate Vi, I have no idea. But my fingers know it apparently. So that's Vi. We'll talk about that. There are some funny jokes about using Vi and all that. We'll discuss that later. But those are basic things that you need to have on every computer. Every machine needs to have it. You just put them together and list them out. I need this. I need that. And then you put that in a role description, role file. Let's call it description. And put that role description in a role folder. And we'll call this role basics. Basics, basic stuff, fundamental stuff. Everybody needs to be up to date. So you mean apt get update. Or if this is a Fedora machine, then yum update. Yum update. Or DNF update. Whatever Windows machine, go Windows update. Make sure that your machines are up to date. That's a requirement I need to have on every machine in my cloud, basic stuff. So I will apply the basics role to every machine I have in my entire business. That's how you can then simplify your work by calling out common things and saying, you know all these machines? All of you, get the basics. So update yourself. Install Git, install BI, install whatever I want. On every machine, I need this. So you will have it. That's one idea. Another idea behind a role can be that I would like to assign these machines as my web servers. And these are machines as my application servers. And these are machines as my database server. So I will create three roles. And my web server, I will say, you know what? You need to get Apache, please. So go get it. So it becomes my web server. So that Apache thing becomes a role in web role. If I want to get this machine to become a database, so I'll define my database role. And in that, I'll say, you know what? You need to be Mongo. So this machine becomes Mongo. And a new machine pops up. So I'll just apply the database role to 45 and 46. And these guys will automatically become Mongo because I applied the database role on these two machines. They'll automatically take on the role of a Mongo and they'll join the party. So the three guys will become a database cluster running Mongo database. That's one scenario. So that's how you can classify the work you need to get done with the roles that you want to assign to a collection of machines. And by the way, Chef will allow you to handle large scale of computers. And so you will want to have these abilities to assign various roles to your machines. And now the item about Burke's file, which is this file. It's currently empty with one line. So we'll change that. And let's go read the instructions and follow along as opposed to deviating from it. So let me just quickly review the instructions. So what do we have here? Where's the Burke's file? Okay, where's my... Okay, maybe the next step will have it. Let me just go there. I'm looking for a... Yeah, I think it was previous step. Maybe I missed. Okay, Burke's file, Burke's file, where are you? Yeah, there it is. So very simple Burke's file here. Just that, that's it. So in our Burke's file, we will put this. So we'll remove the Burke shelf API reference because that's not the source I wanted to go. I wanted to go to the supermarket and do what? I want Burke shelf to go to the supermarket, please, give me this version of NGINX. Sorry, I should say this version of the NGINX cookbook. This is not the NGINX version. This is the cookbook version for NGINX cookbook. So that's what I'm asking Burke shelf to look at the Burke's file and do this, whatever I wrote down. So do that. So it will go to that website, grab this version of this thing and then make it available to me. That's what I want to happen. So I will now make it happen. How do you make it happen? You simply execute Burke's install, Burke's install. So here, your Burke shelf is set up. What you need to now do is, is first of all, cat your Burke's file. And you will see that there's only one reference in there for NGINX 276. That's what we need to grab. So we'll ask Burke shelf, please, would you? Would you please? So would you please say Burke's install will do it? But I don't want to run it like this. I want to make sure that I execute in the discipline control of bundle exec. I want to run it, but in the control of bundle. So it knows which version of Burke shelf will be used. And it knows how to go about doing these things. And it knows exactly how to make things happen. So it will go and do it for me. So it is doing it. And at this stage, I think it is grabbing those books and they're available now. So we have the books available. They, you can access this. There are these books, 7Z, apt, BluePill, NGINX. That's what we wanted, NGINX. We have it now. And we have a bunch of other books also came along. They came along because there was a dependency. So we have books now. And you will see that they are not available in our folder right now, here. Yeah, our cookbooks folder is still empty. I thought you will receive them there, right? Yeah, I said you will receive them in the cookbooks folder. They will show up when you actually need them. Right now, they're not there. They're installed. They're somewhere in the computer, but not in that folder quite yet. This is to simplify a common idea. I think this is where BulkShelf is a little bit smart in that it actually doesn't pollute your kitchen with unnecessary things you don't currently need. You said install. So it installed these items and also created a lock file for you. Just like gem file created a gem file lock, Burks file has a Burk file lock, which basically shows the cross dependency map of all the other cookbooks. So you have the BulkShelf install the Burks or books that you wanted, but it is not here yet because BulkShelf wants to optimize. Imagine you're doing like 300 projects on one machine and each one of them requires the same cookbook. You want 300 copies of the book sitting around in this folder. It's a bad idea. So what BulkShelf does is keep those books separate. Let's go see where it does keep them. So I will show you where it actually goes and keeps the books. It is not in your kitchen right away. But if you go to CD tilde and then CD.BulkShelf, that's where it hides the books. And you can see your books right here. So these are the books that we wanted. And we actually wanted this book, 276, but it brought along some of the other books that are necessary because they have cross dependency on them. You can see that cross dependency in the cross dependency map here. So this is a shorter graph, which shows you the dependency map for this NGINX 276, which is what you wanted, which in turn requires 7-Zip, Windows, apt, lupil, rsyslog, build-essential, 7-Zip again, NGINX, apt, lupil, this, that. So this is the cross dependency map of exact versions. And that graph shows you what the dependencies are for that version of NGINX cookbook. And that's your burst file that defines, I need that. So it obtained all the dependencies as well as the actual book and put down a lock on the burst file lock file. And now you have your cookbooks available to you somewhere they will appear in this cookbook folder automatically when you use it, not right away. Having said, we now have the books, we have the gems, we can proceed forward in actually using the next step in the context of an actual real cloud. So we'll go to some cloud and just going forward from this point onwards, we'll not be running any of these tools except Docker, any of these tools locally on the workstation right here. We'll probably still run Docker locally for some examples before we jump straight to the cloud. By the way, you are free to use the cloud machines anytime you feel like, but I am going to now get ready to prepare a machine that I want to actually use with this exercise in some cloud. So I'll let you name the cloud in the next minute or so. You can name a cloud of your preference. If you don't give me the preference, I'll just go to my cloud preference and just pick a machine there. What I want to really do is create a machine in some cloud and bring a reference to that in my nodes folder. In that node folder, I have a nothing right there, so I'll create a new file and I'll call it something. I'll call it web1.cloudgenie.us. That's a DNS name I'm assigning to that box, so I'm calling it web1, and then putting a JSON file extension, JSON, that is important to remember. So the file name has to be matching the intended DNS name that you want to assign to that box that you will create, and that should be the file name structure. By the way, I said should be, but again, the naming convention is not a strict requirement. I'll describe that in just a minute, but I'm going to follow the requirement. It's not a requirement. I'll follow this approach and save that file as an empty file and fill it up with this, with an empty list, an empty run list, which is empty. Basically, it will do nothing because that's where you specify. What do you want things to happen on the box when you start it, when you start Chef? Well, I'm saying that currently I want nothing to happen, so that's how you write nothing. How does it know where to go and connect? Well, it looks at the name of the file. It says the name is web1.cloudgenie.us.json. So it will go to that machine and look at the run list, and it is empty, so it will gladly do nothing on that machine. The machine is web1.cloudgenie.us. That's the DNS name, and I created that file in this folder, in this folder here. That's the file. It has a JSON extension, like here. So I created that, and I put this empty run list entry in that file. This is how I'm describing that when Chef runs, please do nothing. And of course, we'll keep adding stuff here in that location, so we'll expand our desire and begin with nothing. I don't want nothing to happen, so it will do nothing. I asked you for a name of a cloud company. You didn't tell me anything yet, so I'm just going to grab a cloud that I like, because it's the fastest you can get. So I'm clearing, and I'm just going to a cloud right now. Here we go. So let's go. So I'm going to a cloud of my choice, the one that gets me a machine the fastest, because I'm really, really impatient. DigitalOcean is the one that I think gives me the quickest access to a machine, so I'll use that. So I'll just go log in with the log in button, log in, and log in, and password. And I'm in. And so there is a place to create a machine, so I'll create one. There is a message here on top. Issues with Kubernetes cluster operations 24 minutes ago. Well, we are not dealing with Kubernetes, so there is some issue happening in there. So I'm going to create a new machine, get started with a droplet. That's what they call it, droplets. So I will now create one. So Ubuntu 16.04, 64-bit, that's my preference. And I will say, get me a cheap machine, like $5. That's a good one. And give it to me in San Francisco. That's a good location nearby. And I want to use a key pair that I have currently, which is, I don't know what my key pair is. So it's always a good idea to just get the correct key pair. So just go back to your.ssh folder and examine if you have keys there, and I do. So I'll grab my IDRSA.pubkey and dump it in there. So that key is important. I'll grab it from here, and then new key, and paste it. And this will be called the boot camp key. Let's call it the boot camp key. And save, that's the key I want to use. So I got the key. I have a machine OS selected, price selected, San Francisco location selected, and the key that I just provided, this one. And then I'm going to give it a name. This name, I can use the name web1.cloudgini.us, but this is nonsense. This is not DNS name. So just remember that this is nonsense. This is actually host name. This is not DNS name. So don't name it like a DNS to confuse yourself. I'm going to call it nonsense, because this actually is just a host name. It has nothing or no connection whatsoever with the name that I chose here, which is web1.cloudgini.us.json. That is a DNS name. The DNS name doesn't get created here. It gets created in the DNS server. So we need to have an entry in the DNS server for this IP address. We'll create an A record, by the way, just a minute. So this host name, I create, and it gets created. The machine should be available. The nonsense machine should be available in about a few seconds. As soon as the machine gets ready, I will grab its IP address like that, and then go to my DNS server, which is Cloudflare. And there, I will create a new record, an A record. So I log in, and then I go to Cloudgini.us, and then I go to DNS, and then I identify my DNS record web1, see if I have a machine there already from the last time. And apparently, I do. So I need to change that IP address, delete it, put a new one there like this. I copy from here and put it in Cloudflare like this. And then I'm done. So now my web1.cloudgini.us correctly points to the machine in question, this nonsense machine. It goes there. I can name it something like web1.cloudgini.us, just so I understand. But it needs to be in hostname format. It's not a DNS name, so just keep nonsense. Having said that, let's go dig. So we have a dig command at our hand. We'll go back to our cloud folder and dig. So dig, and then verify whether it actually correctly goes to that same IP address or not. So the dig name is web1.cloudgini.us, and then I want to find the A record for it. So it goes to the right location. This is the IP address that I got from DigitalOcean right there, and that matches the DNS name resolution that I have for A record answer, which is a good thing. Having said, that's the machine that I now have access to. And my public-private key pair. This one already is available to DigitalOcean, so I can have my Chef connect to that machine and run the run list, which is currently empty. That's the idea here right now. Having said that, I will now go back here to our exercise where we were here. And having this definition of a machine or a node that I have defined here, what I will now do is fill it up with something that I have defined here. Fill it up with something useful, like, for example, here. Let's do some useful work as opposed to leaving it empty. So I'll basically fill it up with an action. The action I want is to run the default recipe in the NGINX cookbook. This is the default recipe in NGINX cookbook, which will appear here eventually when Berkshell brings it and puts that here. That will appear. And in there, there will be a recipe called default. That's what I want to run on this machine when Chef runs. And that's the action that I expanded in my run list right now. Initially, it was empty. I just expanded something because I want that box that I created, this box, to become a NGINX server. Right now, it is not. Maybe it is not right now. How do you see that? You can go to that IP address, which we have here, copy it, and try to open it in a browser window. Nothing opens. We have our web1.cloudgini.us open, and nothing opens. We know that. That is true. That is exactly how it should be. Nothing is running there because we just started the box. And so we already understand that piece. What we want to do now is to run this tool. Now that we have our desire called out and our desired state configuration called out in our kitchen, we should do something with it now. Now that we have our ducks in a row, as people call, I want to execute. The execution needs to happen, and I will now run some action. So the action that I want to run is this. I will open up a sublime text to type stuff. So here it is. This. That's the action I want to invoke. And in this action, I think, hold on. Let me just quickly read. Yeah, that is good. So putting this on the side, expanding it a little bit, and looking at what we have. What we have is this instruction that I want to execute. By the way, it's a multi-line command with the slash at the very end indicates that this slash is a trailing slash, meaning there should not be any spaces afterwards. If you have spaces here, that's going to be a problem. So delete any spaces if you have at the end. There are no spaces here. Here will not be any spaces. If you have anything after the slash, the command will not execute properly. It will give you trouble. So now let us dissect this action. We have bundle exec as a prefix. We already know that. What we are really executing is the prepare action using knife solo. Let's go see what that means. The prepare action. This action. Using knife solo, we are going to prepare. And what are we going to target? The target is in line number 10. So let's go see that target here. That's the line number 10. What's the IP address? Well, we don't actually need to use the IP address anymore because we have a structure and a proper DNS entry for that. We can use this instead of the IP address. And that's a better approach. So I'm using the better approach of using a proper DNS entry. The next item we have is a reference to our private key, which is a necessary thing. So which is a necessary thing, that's how you will know that Chef can actually connect and do the prepare action, which is line number eight. Next item we have is line number 14, which is kind of moot. It is not necessary anymore because we are not using an IP address but a proper DNS system. So this line number 14 is actually not necessary. It is strictly a necessary requirement when you have an IP address here. If you use an IP address there, then you need line number 14. But we don't want to use IP address. We have a proper DNS going. So we can get rid of the line number 14 altogether. If you don't want to bother with DNS, then that's the approach. But I think it's a good idea to actually use a proper DNS system. That's what I intend to use. And so what I will now describe is the line number eight. Line number eight, you know bundle exec as a prefix. You know that line number eight we'll talk about right now. You have the reference to the root user in that machine that we created in the cloud, which is right there, line number eight. We already know that. And then line number 10 is a reference to your private key, which is needed for Chef to be able to, Knife to be able to make a connection. So it will do the connection part. Now let's go understand the idea behind this prepare action. This prepare action is basically a fancy way of saying, install Chef. There is also a similar action like prepare. And that action is cook action. And this action basically means run Chef, which is just the fancy Chef way of saying cook, meaning run Chef. There's another action here that is called bootstrap, which basically means prepare plus cook, which means install and run Chef. That's the idea. That's the primary usage of these three actions, prepare action, cook action, and a combination action, which is basically a combo of the two. So bootstrap is a combination of the two above, prepare and cook. And that's the dominant usage of this prepare and cook are the two dominant actions that we will use with Knife solo. We'll see more examples as we deal with them. So that's the idea behind prepare and cook, as you heard me. Now I want to execute this line number, six that I have here. And all of it is just one line. You can make it a multi-line command if you like, but it is short enough. You can put this in one line. So I'll just execute this whole thing in our command line in the workstation right here, in the terminal. And remember, you need to be in the right folder for this, sorry, you need to be in the right folder for this command to succeed. You need to be in the kitchen. You cannot operate anywhere you feel like. You need to be in the kitchen where you have your desire mentioned and your desire is specified is specifically in the nodes folder. And that file contains your desire. And the desire is nginx cookbook default recipe is the run list for this node web1.cloudgini.us.json, which I created a machine out in the cloud. You already know that, you saw that. So now when I execute this action here, which is under the control of bundle exec, so I don't run random software. I know exactly what software versions I'm running. I'm running Knife, which is a part of Chef, the version I chose in my gem file. I'm using the solo version of Chef to prepare my machine here and logging in using the root login and a private key. So that's the prepare action, which basically means install Chef. So preparing your node for use with Chef basically means install Chef. And so let's go see what it does. So right now, before we run this command, I just want to open a side window. And in that window, I want to connect to the machine right there. By the way, this practice of connecting to the machine directly is not necessary, but of course you can. So since I can, I will open a side terminal and connect to the machine that I have, which is web1.cloudgini.us. And just see what we have. So it says, are you sure? And I say, yeah. And so it connects. So it connects to the nonsense box that I have there. This box does not have Chef. We know that it does not have anything. Like you can see ps-ef pipe grep nginx. Pipe grep nginx will show you no nginx. Of course it doesn't, nginx. It doesn't have anything. That is expected. Having said that and having seen that detail, what I would like you to do is come out of the box. And there's no need to keep connections with that box as such because you don't even want to go there. You just wanted to go there to see what you don't have. And that's the nonsense box that I created. I'm gonna quit from that connection and quit the terminal and not mess with the box directly because that's a bad practice. Touching the box directly with a human going there and connecting through SSH and messing around is a bad idea. Don't do that. Use these tools to let them manage the machines out there in the cloud. So that's the first action we'll be doing is to first thing, prepare, which is basically install. And you will see that happen right now. So I'll go invoke bundle exec knife solo prepare action, which is going to connect to that location and install Chef. Let's see how it does. It is telling you it is bootstrapping Chef here. Bootstrapping Chef. Next, it says it is downloading the version of Chef you wanted, 12, 10, 24. That's what you wanted in your gem file. So it has successfully installed and set up the version you asked for. That's it. That's the installation action, the prepare action. And that succeeded with knife solo prepare. Knife solo prepare did it for us. It connected to the machine and installed Chef. And then we have it. We have it where? Do we have it here? You do, but you don't need it here, actually. You need it in the remote machine. You need that thing in that box, which is where we want to actually now run Chef in this box, this box. We need to run Chef right here in the nonsense box. And so we will not go there to run it. Of course, we can. And that's what I think in this exercise, I think we need to go, I think, let me see how I'm doing it here. I think I am, let's go read that a little bit ahead. OK, we are not going directly. We are running the cook action. So the cook action is like this. So here, we'll see the next action, which is cook action. And so here is the action, knife solo cook, as opposed to prepare. And structurally, it is very, very similar to the cook action, the prepare action. They're identical from a structural perspective. You know that this IP address is not necessary. So we are going to use the name that we have allocated to it. And then we have the private key reference, just like before. And then we don't need the last segment, because we are not using IP address. So the dash n is not necessary. Because the DNS name resolves it properly already. So this name reference is simplified by use of DNS. So this is the prepare action that we already ran. Next action is the cook action, which we want to run now. And as a consequence, you will see that the remote computer becomes a NGINX server, because that's what you wanted right there. And right now, in our cookbook folder, we still don't have any cookbooks. That's OK. You will get one when you need it. And so right now, you'll see that it is going to put the cookbooks right in the cookbooks folder as I execute the cook action. Here comes the cook action. And I will invoke this action. It will go remote connect to the machine out there in the cloud and run Chef. And let's see what actually it does when we invoke this action, which is a knife action to cook the machine out there. So knife solo cook that machine. And so we'll say, OK, go cook it. So it is cooking it. And let's see what happens now. So running Chef, it tells you running Chef. And now suddenly, our cookbooks show up. And it is resolving the cookbooks. It is basically sending the entire kitchen to the cloud machine out there and then runs this kitchen with Chef in that location. And so that's what you're looking at right now. And you will see the result in a short summary at the end of the install action, which is the NGINX install action finishing up. As a result of this action, you will see that our box, this box, becomes an NGINX server. And it has succeeded in doing that. It took 26 seconds. And it did a bunch of things. And now you have this box suddenly has become an NGINX server. So when we go to that browser window and open up web1.cloudgini.us, what do you expect to see here? What do you think we should see? You will see a 404 page. And this is probably the first time you will be very happy to see a 404 page, because it tells you that this 404 page was generated by NGINX. So let's go see it now. It tells you, 404 not found. And it is telling you that NGINX is telling you that 404 is not found, the index page not found. That's the configuration that you're looking at right now is the thing succeeded. The desire that you had succeeded. What was the desire? The desire was to make this box this box. We have a DNS reference to that box right there. So that box is the JSON file in the Nodes folder. So that's the entry here. You look at the NGINX cookbook from the cookbooks folder and run the default recipe in the NGINX cookbook, which will convert this box into an NGINX server. That's the configuration. That's why you have the 404 page coming from NGINX when you go to that website. So it succeeded in exactly what we had in mind here. And that's the exercise as to how we did it. In the process, what we did was we did not use the site cookbooks. We did not use roles. We just used a node reference and map list to a DNS name to that IP address. And we did not use data bags. We did not modify this too much. We just used Bulk shelf, a Bulk file to fill up our cookbooks that we wanted, specifically this cookbook. And we ran the default recipe. And we finished that exercise. Simple thing. Now, let's go further expand. And our exercises will become increasingly complex as we go along. So that's the reason why I would like to say that these exercises build on top of each other. So if you understand this detail, please let me know that we proceed forward. Otherwise, I'll stop and explain if you have any questions at this stage before I jump forward. So the complexity will slightly grow as we go along. So that machine that we have, it ran Chef. And so we have it, we are happy to see a 404 page and all that good stuff. And then we proceed forward to check idempotence. How do you check idempotence? Well, you go there and connect to the machine directly. Where is that? SSH, SSH root at, no? I need to type it. Okay, let me just type. SSH and root at web1.cloudgini.us. So I just connect. And then I connected. And here, what I want to do is just mess around with the box. And when I mess around, I am not kidding. I will kill the process. And uninstall the NGINX. It's all the things that we already did. So I'll just quickly uninstall NGINX here. Manually, muck, mess. Create a mess. Just to see how Chef will maintain and fix things. So I'm creating that mess by removing NGINX. Simply saying that it is, what, apt? Good. Uninstall NGINX. And, oh, there's a remove action. Not uninstall, it's remove. So I never remember these things. Remove NGINX with a dash y. And it's doing it. And then we also remove the dependencies. So apt, auto remove, async, purge. So it removes the other things that we don't need anymore. And as a consequence, our NGINX is dead. Which is exactly what I wanted. I wanted to kill it. So web one should show us nothing. There we go, nothing. Now Chef should run on its own automatically every so often. And we haven't set that up yet. We can set up a cron job on that nonsense box directly. But we haven't done that yet. So what I want to do is simulate. How do you simulate Chef to run again? You basically run the cook action one more time. One more time, so you have another window open up. And in that other window, another terminal window. We will go to our cloud folder and say, hey cook, please cook it. So oops, oops, oops, I'm typed properly. So I'll say bundle exec, knife, solo, cook, knife, solo, cook, and then root at web one.cloudgenie.us. That's how you cook. So it goes and cooks. And so it will again put NGINX back in place and run it and all that good stuff. And as a consequence, we'll see the 404 page one more time. And that's what's going to happen once this finishes. So that's the idea behind idempotence action that we are looking at. We'll now go to the next step. What we want to do now is to see how we can define a role for a set of machines, for example. And so this that we are doing right now is not actually an exercise, but more of a concept to understand. We'll get to an exercise, this particular page that you're looking at here, define a role for your nodes. By the way, this thing seems to have finished NGINX. So we should be able to go and check web one.cloudgenie.us, should show us a 404 page again, there it is. Okay, so it succeeds. Nice, next. This idea that we are now looking at is about creating roles. Now role idea is basically you create a type of, you classify some function that you want to apply to a given set of machines. So that right now we are dealing with just one machine. So what I want to do is see if we can construct a role. So here I'll copy this and put this role in a new file in the roles folder, call it my web role. And then dump this segment there. And what I'm doing right now is I created a new file here called web.json, and I put that in the roles folder and it contains my run list. So I want to move the run list here, which contains the NGINX definition in that file. I moved it here actually. So the default recipe in the NGINX cookbook and the run list portion that was in that file is now here. In addition to that, I am also calling out some default attributes for NGINX to listen on port number 80 as well as 443 in preparation for my HTTPS usage. This is the HTTP port. This is the HTTPS port. So I want to prepare my setup for both usage and that's why I'm asking NGINX to listen for this and that both. And that is what I want because I would like to have NGINX listen. So I expand the definition and this can be done with choosing attributes like this segment does. You can assign various attributes to a given cookbook, but where do these things come from? Where do I get the idea? Well, you can get the ideas about default attributes by looking at the cookbook itself. So let's go expand the cookbook and see what is inside. We'll go see the cookbook, the NGINX cookbook and the attribute section. And there are a whole bunch of things you can customize. And so we'll just focus on the default attributes. And here you can see that the port attribute is only eight zero. So if you want to expand this, you will go like this, make it 80 and 443 to expand the scope by expanding the default attributes for NGINX listen ports. And of course you have a run list. So this is how you will, this structure will allow you to customize your role definitions to meet exactly what you want for a given application to open a particular port, maybe address some other feature set in the application that is getting installed through the use of that cookbook. And now that you have this role, you want to actually make use of the role instead of directly invoking the default recipe in NGINX cookbook. You want to maybe make use of this role instead. So you can make that change very, very effortlessly. How do you do that? You basically swap the recipe NGINX reference here with a role reference called web. So now, now what do you have? Is that this was before it was like this. Now you have made this point to the web role, to the web JSON in the role folder. And this is your JSON now for the machine, for the node, the nodes folder. And as a consequence, what will happen when you invoke Chef on that machine, that it will look at the run list, which will reference the role here and it will automatically pull up the appropriate attributes defined here. And of course at the end, you have the default recipe in NGINX cookbook. And that cookbook is sitting right here, somewhere inside. So that's the scenario we just twisted a little bit to allow us to have the flexibility to expand whatever we wanted to choose our attributes we would like to have for our NGINX software to get implemented, to listen for specific ports that we wanted to listen. So we expand the HTTPS capability as an example. And with this modification, we can still execute the same cook action and it will also succeed. You can see the action cooking action is happening here. And let's go see that. So I will now erase my ink and run this. So erasing the ink again and going back to the terminal and running Chef one more time. So here it goes same way. This bundle exec-knives will cook. It will also cook, but this time it will cook with a role as opposed to cooking directly with a cookbook. So slightly changed the idea, using roles. So that's this idea, it'll finish. Next, next idea. The next idea is we can assign multiple roles to a given node. So maybe if we want to examine and have this same box that we have, maybe we want to expand and put a bunch of things on the same box. Like this box currently is just NGINX server. Maybe I want to make it a database server also. Maybe that's a short test I want to run. And I want to have a database alongside an NGINX server, both on the same box. But I can very easily implement that by creating another such role definition. Let me call it database.json. And in that JSON file, I will write something like this. And which is this description. And this is just an illustration. I'm not actually running this, but the idea here is that you will have PostgreSQL database, the default recipe for PostgreSQL, expanding the run list. And that will invoke and install not only the web role, but also the PostgreSQL role, which is a PostgreSQL recipe, which will expand our scope of this machine to become NGINX server as well as a database server together at the same time. The idea is to assign multiple roles to a node. You can accomplish that scenario if you like. And that is just an illustration, by the way. Don't do this step because it is not the way, it's purely just an illustration to understand the concept. There are lots of other things that are necessary to make this scenario of PostgreSQL succeed. So if you try that, it will probably fail. So this is just an illustration. Not for execution, not ready for execution yet. This one is not. Let's go forward. Let's do this. So next step. You can also similarly assign attributes. The idea of attributes, like I mentioned here. There are a bunch of attributes you will see in every cookbook will have a folder called attributes. And there you will find a bunch of things that it needs to deal with. Like for example, here in that source army, you can specify whether you want NGINX software to be built from source, for example. You can potentially go to, use this cookbook to go to NGINX website and download the source code, the version that you want. For example, the latest version as of this mainline. So NGINX 1.15.8 mainline version that you want. You can get that as fresh directly from source and compiled using the compiled attributes defined in the source RB attribute override. You need to make some changes if you want such scenarios. There are a variety of attributes available for you to understand. These are all the configurations that are possible in using the NGINX software as designed by the software developers. And as the attributes are created for you by the cookbook developers. The cookbook developers are different from the software developers. Software developers develop the NGINX software. And of course, cookbook developers will develop the cookbook that will implement that software. So that's the underlying idea behind modifying attributes. For example, if you go to another thing, here is an example of Apache cookbook. And so you can see that you can modify timeout settings. And so I think the example here I think mentioned is, yeah, the same idea about port number 80 and 443 expanded for default attribute for Apache software. And this is the similar example of NGINX. We are looking at Apache example. Again, these are not executable exercises, but more of illustrations. And they're not actually exercises. So just remember in my, don't run it in your workstation. It's not going to work. Another example is about expanding some timeout values. So maybe if you're testing something and you want to keep that, keep a live timeout for Apache to be a little bit longer than usual, 30 seconds. If you're testing something, you may want to override certain attributes. It will let you do that. And that is typically useful in a test scenario. If you're testing something, you want to have a longer timeout so you can actually finish your test. That scenario, maybe the default values are low and so you can expand a different timeout value like this. The default timeouts are probably about five seconds. I don't exactly know what the defaults are, but you can always read the documentation to find out what the default values are and modify them if you like. These tools help you change attributes the way you want. That's the underlying idea of attributes. Having said, let's go forward. Okay, next. So what I would like to do next is to understand the idea of environment. Again, this is not an exercise. This is not a part of the exercise. This is just an illustration of how would you configure an environment. So here is an example of a development environment when you want to further extend your NGINX timeout values for all the machines in your development environment. So you will probably have something like, hold on. If you look at your environment folder here, you may want to create a new file in there that will contain this definition. And that definition might include something like in my development environments as I develop some software, I would like my NGINX timeout values to be about 120 seconds or two minutes of timeout. You can adjust that. If you're testing, developing, building something, you could set all the development machines in my dev environment needs to be following this timeout value for NGINX. So it will automatically handle and manage it. And if you're putting the same cookbook or the same kitchen, if I apply that to a production environment, the timeout values may be a little bit different, maybe not 120. It's really up to you as to what values you want to pick and choose. You could have different values for different environments depending on your business needs. That's the underlying idea behind creating environments. And we'll get to actual examples in a slightly more complicated fashion right now. We are just discussing these concepts for us to understand what these things are and how do we put that to practice, erasing the ink here. Come on, go away, yeah. And then we will go to the next segment. Now comes the fun part, which is the idea of data bags, which is actually fun in the sense that you can store secrets. But what's the fun there? The fun is not just in storing secrets, but in storing secrets in a way that will hide it from other people. That's where the fun comes. So you want to store your data bag in, and you will store your password and username and other details in there in bags as items in a bag. And that's what we will do as a first exercise. But then I don't want to store my user and password details in plain text so that people will be able to see it. And that's not what I want. So I want to store user and password detail in that folder just like that, but encrypted. And that's the key idea, which makes it a little bit interesting. And that's what I will now demonstrate to you. How do you encrypt something like a username and password in a plain text file, but still encrypted? And let's go play with that scenario. So for that to happen, we need to modify Chef Solo because Chef Solo by definition, by its original creation at the time in GitHub, you will find that it doesn't support data bag. This data bag feature is not available in Chef Solo. But it is open source. What does that mean? It means that other people have come up and built that capability that was missing in there. So that capability comes separate using this gem. It's a supplement gem that basically enhances the capability and adds the data bag capability to the Knife Solo gem. The solo gem, the Chef Solo Knife Solo operations has that extra feature which is available from outside, not in the main source, but a separate source. That source is this. So Knife Solo data bag support. So it's a separate gem we need to add. And to add a gem is very, very simple idea. What do we need to do is just go to our gem file here and say, hey, I want one more gem. So just go there and say, here, I need one more gem. We have our existing four gem listed there already, 060, 435. We have 12, 10, 24, and the rack gem. Now we need one more. So we'll get that. How do we go there? Just copy it from here. And dump it right there. Now we have it. Our gem file expanded. This expanded gem file, it is simply for us to go bundle install one more time. And then we do that. What we should have and see in our, let me quit from here, extra terminal. So going back to the terminal, we are connected to the nonsense box right there. So we'll quit from there. Go back to our local machine in the cloud folder. And there, we need to bundle install or bundle update. Bundle update is a better idea. Simply look at the existing gems and just add the new gem we just want so that extra gem we have, solo data bag, will bring on data back capabilities to the Knife solo way of execution. So now we have capabilities to manage data bags. So we'll now use it. Using it, actually, you will see that this Knife command now has new capabilities. Before, it had like a cook action and a prepare action, prepare and cook action, and bootstrap action. Now it has more actions. It has the new actions is added onto it. Earlier, it was prepare action, bootstrap action, cook action. There was an init action also that we initialized our entire kitchen using that action. There is also a clean action, which I never use because it's, I just delete the whole folder and create it again most of the time. So I rarely use the clean action, but these are the existing actions available as a part of the original Chef solo implementation. What we just did is add data bag capabilities to it. So now we have a data bag create action, data bag edit action, data bag list action, data bag show bag item action. What does that do? Let's play with it to find out. New actions available, we'll just play with it. The first action I want to do is to actually create bag. How do you create? Simply just type the commands, simply like this. I'm going to get my mouse working and here's the action. So this is going to be creating an unencrypted data bag. So unencrypted, not yet encrypted, which is the first step. We will see how we can create a bag. So let's go paste and understand that this is going to be in the control of bundle exec. So give us discipline, force our versions, knife, solo, data, bag, create, and this is going to be the bag name and this is going to be the item name. When we look at the create action, it is the bag name followed by item name. So this is your item, this is your bag, this is the create action, and it's going to create a data bag. That's what you see. So we create a bag called pass. In that bag, we'll put an item called MySQL. The items and the bags will show up in our data bag folder right there, here. That's where you will see it pop up when I run this command. So I will now create a bag called pass with an item called MySQL. And as soon as I hit it, I see an editor open up. This g-edit editor is where it expects you to fill up stuff. My plan is to fill it up with my password. And so here is the detail I want to fill it up with. My password is super secret pass. That's my password. So I want to save it and close it. And so I saved it, close it, and item got created. The item shows up inside the pass folder in that is the item. And I can read it. It's just plain text. So it is not encrypted. So that's a scenario of usage, but it's not the best. It is not encrypted. But just understand that this is the one method. It is not encrypted scenario. Now we'll now switch to the encrypted scenario. In this scenario, you see that it is basically a JSON file stored as an item which is on sitting in the pass folder, which is the bag. And the bag is sitting in the bags folder. That's the usage scenario for an unencrypted bag. So we've got that. Next, what we want to do next is to just execute the commands to interface with the show bag item action. That's a very simple thing. We can just say bundle exec knife solo bag, show, and then the bag name was pass. And then the item was MySQL. So it will just show you the content from the JSON that you have, that you can always see it indirectly in the editor. You can just see in the atom editor and examine the content right there. So what's the big deal of this command? It just shows the pass. The deal is that basically bag usage is typically stored in a Chef server. So you don't have the visibility to just go and examine the Chef server just like an editor. You can examine the editor content like right now. It's easy to just see it here. But if this bag is stored in a Chef server, there is no visibility to this. The only way you can actually access is through this command. So that's where it will come back with an ID and a password content of the bag here. We'll dump it right in the command line because that's the way to operate interface with a Chef server. In our local example of a Chef solo example, it makes it easier to understand because it lets you see the content here. But that's not always the case when you're dealing with other scenario usage. So like for Chef server examples, you will not be able to see the detail right here, like you see here, except unless you run the command to show a bag with an item. So it shows. You can see it visually also, but that's unencrypted. Now, let's go to understand how do we actually encrypt these items so that even if you see it, you still will not understand what's there. And so that's the whole idea behind encryption. So to encrypt something, we need an encryption key. Just like a private key, public key, this key, that key, we are going to create our own key. Our not key pair, just a key. And a key is basically a random number, really, really long random number, randomly generated. So you can create a random number simply by going like this. Open SSL is the library to generate a random number. And I encoded with base64 and give me a 512 character long random number. And then it goes, boom, you got that. That's your random string. It has 512 characters encoded base64 and the string begins here. And then there is a new line at the end of C and then it begins again, D. And then there's a new line at the number five and then begins again with K and new line like that. So these new lines is not what I wanted. We need to get rid of the new line after C, after five, after S, after one. There's a new line character. I hope you understand what I'm talking about. New line is a character that is embedded as octal 10 or octal 13. If you know what I'm talking about, please tell me that you understand new line, which is old mechanical typewriter had a new line character. That's what I'm talking about. That's what this thing is. So we want to get rid of those things. I want to get just one single long string of characters in these random generated characters in base64 encoded 512 long. So I want to trim this. So I will use the command to trim. How do you trim it? You basically pipe it through a tr command and delete any carriage returns, any new lines, and then get the output. So now you see another output, a different random generator, different random base64, 512 character long, but with new lines and carriage returns deleted, trimmed out. The return and enter at the end of these characters, they are gone. Now, this is just one long string all the way up to here, base64 encoded, because I trimmed out all the slash r slash n. That's what I wanted. I'm building this encryption key for me. So I can actually dump this key into redirect it into a file. The only way I want to put this is in the.chef folder, because it's going to be hidden, and I'll call it encrypt. It's a long typo, and let me just copy paste that long name. That's a conventional name that we want to use. So that's what I want to use is this name. That's the convention from Chef. So that's the name that I want to have. This key should go in that file. And as soon as I enter that, I see a new file pop up. And that file is that one in the Chef folder that gets created. And it has only one line, as you can see, one line. See, there's no line number two here. I don't want to have a line number two. All these characters should go in one line. That's the requirement of a key. Now that I have it, I can see it, I can cat and see it. That's the key. By the way, this key is not supposed to be shown to other people. It's supposed to be only within the team that is working on the project. So you keep this key as an encryption key to keep your secrets secret. So now that we have the key, I will use this key and then create another bag, and this time an encrypted data bag. So I see that there is a copy and paste trouble in this website. I will fix it. It was hard to copy the whole thing. I copied, but you might find it hard. So I will fix that. So the copy paste that I did, I just understand what I just copied. And before I execute, I'll help you understand what did I just do. So again, bundle exec, knife solo, data bag. I want to create a new bag, call it password, item name is MySQL. So very same like before, except before the bag name was pass. The bag name is passwords. And it has an item with the same name before like before, but it has a new item here called dash, dash secret file, and then the encrypted data bag secret. So when I go like this, it actually create a new item encrypted with this key and put that in a bag called passwords, not this. That was the older example. I'm not ready. That pass bag exists. It is unencrypted. This one encrypted. So let's go create one. So I'll create. As soon as I create, it opens up the editor, but I would like to fill up my super secret password. Fill it up like this and save and close. And when I close the bag item gets created. You can see it here. There is a pass back from before which contains this item and this new password that I created, which I think is a super duper secret. It is not just super secret. It is super duper secret, but let's go see it. And here is the passwords bag with the super duper secret password, but whatever happened to that and what you're looking at right now is an encrypted version of the password. The encrypted password is stored in this JSON between these entries. Now from that to this, that whole thing contains an encrypted data with a Cypher AES encryption, 256-bit encryption. And the encryption key is this that you created just now. So that's your encrypted data bag. And even though you can see it, you don't understand what it is unless you decrypt it. So how do you decrypt a bag? You basically go like that again. This time instead of create action, you say show action like before it was create. This time it is show. So when you show the item, it will show it to you. And this is the super duper secret that I typed as opposed to the other one, which is just secret. And so it decrypts this item called MySQL in the passwords bag using the secret file, which is the encryption key. Now, if I try to run that command without the encryption key, you will see that I cannot figure out what my password is. I see the data, but I still don't know what the password is. I see encrypted data and I have no idea what the password actually is unless I decrypt, which is this. Then I see it. So that's the underlying idea behind encryption of a data bag. It is very simple using OpenSSL random generation and using it as a cipher or a key. That's what you just saw. Now, every time typing all these things, it's kind of boring and long. So we'll simplify this. What do we do? We would like to put this reference in our KNIFE-RB so that KNIFE-RB knows what the secret is. Currently, it doesn't. So this KNIFE-RB that we have, it has no idea what your encryption secret is. So we will need to do is go to line number six in KNIFE-RB and uncomment like that. Line number six now tells KNIFE-RB that I'm using an encrypted data bag secret and my secret is this, not that. So now I have told my KNIFE configuration that I'm using a encrypted data bag secret and my secret file is stored in the.chef folder and that is my secret. Having seen this edit that I just made, what I want you to do now is to be able to run that action again, but this time don't need to pass the secret file all along. Don't pass it anymore because KNIFE knows that you mean to use the secret. So it just immediately gives you the secret super-duper secret decrypts for you and gives it to you. Anytime you have a question, you should actually stop me. Now we'll do a next exercise, another exercise which is written down there. So this exercise, let's go first discuss what this thing means and then we'll do it. This is a live exercise, I'll do it with you. We will understand first of all what the exercise is. So this exercise, let's go read. The exercise involves setting up a node, a node means a machine, a machine can be in any cloud of your choice that has MySQL database server software ready with root password and not just any root password, but a password that you select, like super-duper secret. And so that's the desired outcome is I would like to have a node that is ready, accessible online via SSH, which is expected of any cloud. You just go there and then it needs to have pre-configured MySQL server installed, running and ready with the root password that you select. You can do these actions very, very simply by saying apt-get install. So you say apt install MySQL and then you follow along prompts and then the window will open and say, ask your password. So what's your password? So you just type in your password, then you'll say, I'll repeat your password, type in your password again. And then you say, okay. And then MySQL server install finishes. That's how MySQL server installation happens. And this is a manual step. Imagine now you want to do the same action on a hundred machines, thousand machines. It's boring. So you want to automate. So that's the idea is this exercise. So we'll just do it one machine right now, but the idea is to be able to automate. So you have to select a password upfront, put that somewhere. We are not using the data bag, the encrypted data bag that I just described. We're not using that right now. Keeping things simple. We will go to complicated stuff and you probably will find that it gets really, really complicated at some point along in the series of exercises. And if that happens, just ask for help. It will get complex. I am not kidding. It will get really, really deep and in the, what's the word, what's the slang word for it? Weeds, I think, yeah, they're really, really deep and you will probably not like it, but I guess that's okay. Yeah. You can always ask for help. It is, you know, way too much. I think it is all the way nuts and bolts to the lowest level of machines is where that exercise will go to help you really understand what things are under the hood. And that's the, I think the depth that I expect you to have. So again, that exercise is by the way here, 26, I think this one is the extensive, I already mentioned it. I mentioned it like that. So it is one of the most intense exercises in this program. So pay careful attention and you will emerge a winner. If you need help, of course you can, I'm here all the time. So you can always, by the way, you can look ahead if you like, see how depth, what level of depth it goes to. And if you, by the way, most people actually complete this exercise. That's where the funny part is. People complete this exercise with great effort, but they actually do, which is what I admire about people who attend our programs, which is they actually go to the depth that I expect them to go. And that's why I keep it. I did not drop this exercise. It is mind numbing to say that there's no other way to say it. It might take like three hours nonstop for a fresh first timer to do it. It takes me about, while I'm talking, takes me about one and a half hours while I'm talking. If I really want to do it, like everything by hand, step by step might take me like half an hour without stocking, without stopping and just nonstop go, go, go, then it might take 30 minutes for me to finish the exercise. But it might take about two, three hours for you easy. Having said that's the depth exercise, I want you to actually do it. And at this stage, I would like you to know that, you know, many of you are actually busy doing other things like, you know, your work, for example, and other things. So if you're busy, let me tell you a secret. Just do this one exercise that will cover the entire gamut or what we are talking about in just one exercise. If you're doing one exercise about chef, this is it. You can skip all other exercises. This is a complete comprehensive step by step, begin from scratch exercise rest. You can just watch me do it. That's good enough. But if you want to play along, you're welcome. If you're busy, do this one, the only one for chef, the only one, this one, this is the item number, I don't remember the item number, but that's the title. So I'll paste a link for you. So it's coming up, I think in maybe two sessions from today, we'll do this exercise. Two or three, I don't exactly remember when, but it's coming. So we are not there yet. So going back a step, what we are doing right now is the idea behind setting up a MySQL, the simple baby steps. So that MySQL, where is that? Let me go back button, back, yeah, so here is that. So we need to set up a box and make it our MySQL server with our chosen password. So that's the action we'll do. So we need to use Ubuntu 14.04, by the way, this is a cautionary note. To keep this exercise really, really simple, I deliberately chose a specific version, and that is, I hope it is still available, so let's go see that. Let's go to droplets, create a droplet, and let's see if we can find 14.04, yes, we can, awesome. So 14.04, that's the one you should be using for this one exercise specifically, so just to keep the exercise simple. I'm using a slightly older version of Ubuntu, and that is something to take note of for this. I'll keep these mentions right up front. This is the base OS you need, and this will help me simplify. You can choose any cloud you like as long as the version is this. This simplifies my exercise steps, because this is one of the first exercises you will probably do on your own. That's why I kept it simple, and I have actually solutions provided to you, so you can actually follow along and do it. This is going to be the homework for later after the session. You can do it whenever you feel like. The solution is available here, please do it, and when you do this, choose this 14.04, that's a requirement. If you don't choose this, your exercise will fail, and add to your complexity for no good reason. For the first time, just stick to this. Having said, I will know that I have this machine that I am running here in the cloud there. This machine that is running right there is not 14.04, which means it needs to die, so I'm going to kill it. This machine dies now, so I say, okay, bye-bye. The machine is dead. Now, I create a new droplet, and this time, I'll remember to create a 14.04 droplet, 64-bit, and a cheap machine is good enough, and go to San Francisco, the nearby location, choose the boot camp key that I have in my machine, and give it whatever name you like. This name doesn't matter, and then create. The box is getting ready, while we proceed to the next step. In the next step, what we want is the machine getting ready. We want to check if it is accessible on the internet via SSH, so we'll do that, and then it has to have MySQL server installed, running and ready with the root password, and after a chef run, meaning a chef cook, prepare means install, and cook means run. Chef prepare, chef cook basically means install and run. After a chef run, you need to be able to log on to the MySQL console on that node on this machine, the DigitalOcean machine. We need to be able to check that. That's the test. This is a solution to the exercise. There's also a test to verify, verification of the solution. That step is also provided. How do you verify that? It works. We'll go run these things now, but before we run, we need to understand what's going on and how are we dealing with these ideas. In our exercise, in that folder that we have right now here, there are a bunch of things that are not relevant to the exercise. For example, in our cookbooks, we have a bunch of unnecessary books. We have nginx and a bunch of other things. I'm going to delete the cookbook folder right there, go bye-bye. The gem file is fine, but the burks file is not correct because it is saying nginx and I don't want nginx. What do I want? Well, I want MySQL and I don't want nginx, so I need to grab MySQL, not nginx. I'll just put MySQL in there, right there. That's the version that I want. To keep things simple, I choose a slightly older version. This is an older version. This simplifies the understanding of the concept in this particular exercise. Having said, I need to now run Berkshelf because I have a new book to get. That book will come and I'll ask my Berkshelf, bundle exec, burks, and then install or update either way. I think I typed it wrong, but I think it handles typos comfortably and it installs MySQL. Cookbook already, that's nice. Having seen that part, what I want to do now is that I will now define another machine and a name for that. The machine that I have created already, it has this, let me go to Cloudflare, and it had that IP address right there, this one, has this IP address, I'll copy it, and that IP address needs to be assigned to a name, a DNS name. That name I'm choosing right now as my database. That should be a name. Although, in the exercise, I have written down a name, web2. Just note that I'm slightly deviating this for a deliberate reason because it doesn't make sense to have this machine named web because it's actually not a web server, it's a database server, so I should label it correctly. It's purely cosmetic, it doesn't matter too much, but I'm going to label it so it makes a slightly better sense, which means I will edit this out and put DB in there soon. For right now, just doing it by hand and I'll actually edit that. So you will see it edited in as soon as I find a few minutes, I'll edit that and move it out. In my DNS, you will probably find there is a web2 already. No, not here. You will find there's a web2 already. Come on. Web2 from the last run, so I need to delete that entry, web2 goes away, and I'm creating a new one called db. Oh, db can be a scary name. It is scary because I may have used it, so I'll call it db1 instead and not call it db because db can be an existing real-life production database server, so I don't want to mess with it. I'll call it db1, just clarifying that piece and now create. Let's call it db1 and I don't have it now, so I'll say your name is db1 and the IP address is from that location, copied, put it here like that, this, and two-minute TTL and add the record. If you are using Cloudflare, you need to be aware of the fact that this thing should not be orange. So just remember, if you're using Cloudflare like some of you are, do not keep this orange. Keep it like gray and I'll tell you about, this is about content delivery network feature and that feature you don't want to use right now. So you want to disable the orange color. So don't keep it like this. Orange is for content delivery network. You don't want to use Cloudflare CDN for this example. So you disable it and then add the record. Now you have db1 pointing to that IP address, which means you need to dig. You need to dig db1 and get the A record, let's see what comes up and it comes up correctly, which is sweet. So we close Cloudflare now and then we will proceed forward. So we need to define a new node by that name, which means we need to go and further clean up here. So what can we clean up? Well, we are not using data bags, not using environments. We have a node here that we don't have, we have killed that one already. So we're going to delete that. That node is dead. The NGINX node, we need to create a new one here. We call it db1.cloud, typo, typo, cloudgenie.us.json and then fill it up with this stuff. Like this is a file. It needs to get that stuff. And this file gets this stuff and let's save it. And I'll describe what this thing is and why it matters. What we are really doing here is carefully reviewing the entire kitchen that we have and cutting out things that we don't need because it is not necessary to just simplify our understanding. The data bags we are not using, so we are going to get rid of it. Again deleting this is not required. It will be ignored, so you don't have to delete. But I'm deleting to clean up and make sure that you truly understand the necessary components for this exercise to complete. We don't need environments because we are not using them right now, so removing them from the view. We don't use roles in this exercise. We are going to get rid of that also. We don't use site cookbooks either because we are not creating a new cookbook. I'm leaving the git keep, git ignore alone because they are mostly empty. But if you want, I can delete that. We are not using git either, so we can get rid of the git keep and git ignore files also. But get rid of them. So just clean up. We have used Berkshelf with that cookbook is now available. So there's a corresponding log file available. You can see that this is a simple dependency map. The dependency is that MySQL cookbook depends on the mysql community cookbook. Another cookbook it depends on, that's the graph for dependency that you show in the log file here. And similarly, there's a gem file that we have which contains the dependencies, sorry, the gems that we need for this exercise. So we have a corresponding lock right there. And now the node that we created. This node references this entry. Let's go item by item, read that. In our.shf folder, we have the encryption secret that we created manually. We don't need that also. And KnifeRB is a necessary thing to have. So we are keeping it as is. And we'll have to change the sequence here later on. Like I mentioned before, give precedence to site cookbooks over cookbooks. We'll do that later. And for right now, let's go understand what this thing is. So what we are doing is in our Berk shelf, we have used this cookbook, mysql cookbook. If you look at that version of mysql cookbook, it will describe the attributes that we have actually referenced here in our JSON for the node that we created in that name. So I said, go look at the cookbook here, that version number. And I casually mentioned it without telling you how to do it. So the way to do that is to go look for the mysql cookbook on GitHub. And here it is, the source. View the source. Now, that source will give you a variety of version numbers. So we'll go look at the tags, and the version we look for is 563. So we go down, and we look for 563, and it is 563. That one. We click on it. And then here what we see is that there are attributes. And so we are looking at the tag called 563. And this is mysql cookbook attribute section, only one file here. And that's the reason why it is a whole lot simpler to deal with this version. Because in those days, I think it is last year or something, older cookbook, slightly older cookbook, this version, the cookbook was a whole lot simpler for us to understand the detail that I'm talking about right now. That's why we are using that version, which means if I go look at the attributes provided to me in the 563 version of the mysql cookbook, the defaults are simple to understand. That's why we are choosing this example for us to understand the concept. What we are really trying to do is we are looking at the mysql cookbook version 563 and looking at the default attributes here, default attributes in the mysql 563. That's what we are looking at. Now, what do we look inside? Well, we look for the attributes we want to modify. And so what do we want to modify? Well, we first of all see what attributes we have. There's a service name, keep it default, don't care about it. There are some passwords defined here. And one of them is the mysql server root password. And the password value by default is this. I like random passwords. Why I don't like that value? I want to change it. I want to change it something as difficult as one, two, three, I'm just kidding. But that's my choice, not somebody else's choice. So I choose this to be one, two, and three, now one, two, three, like that string. That's my complex super grouper complex password, one, two, three, that's my choice. The default mysql server Debian password is not assigned, I choose that to be 456. The default mysql server replication password is not assigned, so I choose that to be 789. Whatever I choose, I can choose whatever I want here. And these values will override, not overwrite, override these values here. That's what I want to happen. So that's why I have called out mysql. And then server root password, server Debian password, and server replication password with these values. And then run list. In run list, I'm looking at the mysql server cookbook, sorry, hold on, let me describe how to read that. So the reading part is somewhat tricky. The way to read this statement is to look at the mysql cookbook and the server recipe in the mysql cookbook. That's how you read. So that means it is not the default recipe, but the server recipe in mysql cookbook. So we have to go to the mysql cookbook here and look at recipes. Right now we are looking at attributes. So here are the attributes file, the only attribute file we have was default RV. Now we go to the mysql cookbook version 563 and look at recipes. In there we have three recipes. By the way, there is no default recipe because mysql software comes in two parts. One of them is the client part. If you want to just install the client, mysql client software, you will use this recipe. But we don't want to install just the client. You want to get the server software. That's why it is called out by name, get the server software and this is deprecated. So you can ignore this. So it will install and execute the mysql server recipe from the mysql cookbook and implement that as a run list for this node when we prepare and cook. Prepare means install chef, cook means run chef. Run chef on that box, which is somewhere in the cloud here, digital ocean cloud. So we clear my ink and get ready to run this action. The action again repeating is that it will not work on 16.04. It needs to be 14.04. That's a requirement. That's what I have chosen here. The machine is a 14.04 Ubuntu, so it will work. Having said that, let's get it to work. So what does that mean? It means we need to run chef. Before we run, we need to install chef. How do you do that? You can do it in one shot. One shot meaning bootstrap action, combination action. The combination action is simply like this. Before we ran the prepare action and the cook action, this time we'll run the combination action bootstrap. This time the action goes to db1.cloudgini.us as opposed to web1 because it's a database server, so different name. So that action, the bootstrap action will basically do both the two things together. It will prepare and cook in one shot and make this box, which is currently empty blank just to 1.2.14.04, it will convert that box and grow up to become a MySQL server and not just any random MySQL server, but a server that runs using my password that I chose. And that's what I will test for and validate for. So I need to make it become my MySQL with my password. And now I will execute this line, which will implement the prepare action and the cook action together in one shot. And that's what's going to happen now. So grab this line and go to the terminal. Make sure that you are in the correct folder, check the listing and run and go. So it will now go to the cloud, install Chef, run Chef, meaning it will go and do what you wanted to do. What did we want? We wanted this desired outcome. The desired outcome will become successful. Already it is 1.2.14.04, it is accessible via SSH, as you can see, it already connected to it and it is installing Chef right now. And then there are lots of things, so it will go fast. But it is installing Chef and then when it runs Chef, it will then grab the MySQL cookbook and installing MySQL and then configuring it and then putting your root password 1, 2, 3, and all that. You will see it popping up as soon as the action of install finishes. The install action finishes, you will see the password actions happen. That will also happen and then it will report that it did, there it is, select 1, 2, 3, the password action happened. And yeah, it's finished. So it finished doing its thing in 25 seconds and then we are ready. So what does it mean by ready? How do we know we succeeded? It tells you it succeeded. But how do we know? Well, we go and check, we'll go check for things like, are you sure you have MySQL? So let's go check. So we'll go to the machine directly to verify. So we'll go root at db1.connect please, connected. Now what? We check whether we have MySQL server installed. So how do you do that? You say MySQL and d for the daemon option for the server name is MySQL d and then check for the version. We have it installed. Now you will see whether it is running or not. We grab for it in process list. And you'll see that it is running right there. Okay, it's running. That's good. But what about access? Can I log in to that MySQL database server using my password? That's the last test, the verification test. So we'll use MySQL client to log in as the root user. And the password that I want to use is, it's asking me for the password. I'm going to enter the password that I know I have chosen and the password I chose was a very secret password called 123. So I just typed it and then I enter. And now I'm connected to the database. Now here you can see that I can see show databases and do all your database operations that you do as usual, business as usual, so you can see you interface with MySQL in this example. And then I'm done using my database, so I quit basically after verification. I succeeded in setting up MySQL with my chosen password without touching the box. And I went back to check, cross-check, validate, verify, and it worked. So that's the idea. Now some preparation for the next session. By the way, whenever you create a box like this, you don't forget to delete it. That will be a bad thing, bad for your credit card. So remember to destroy and kill the machine. That is a necessary step. You could always do that and make it a habit to, if you take some resource from some cloud, make sure that you go back and remove it, release it and extinguish and terminate and destroy and shoot the cow, whatever name you want to use, but do this action or get rid of it. If you don't get rid of it, then you are accumulating charges on your credit card without conscious knowledge. That is the bad part. If you want a machine, keep it, run it, use it, no problem. It's your money after all. So I'm just telling you that even if you have a freebie, it doesn't make sense to waste it resources. So having said, let's go read the next action. There are some actions expected now for some logistics that I would like you to do. And so the logistics needed for the next segment, which is going to be Monday. I expect you to have a Chef server out of magic. So I like you to have a Chef server, each one of your own personal Chef server. So how do you get it? You go to here in this website, what's it called? Manage.chef.io. So we'll just rent one for free. So do not spend any money. There's no need to, but you go to this location in Slack chat and sign up. When you sign up, it'll let you create an account. This account will be created like that. So once I create an account, I can log in, so you can see the Chef server right here. This is my Chef server. You will have your own Chef server like that. And we'll use it. Right now it is blank, empty. And that's just this example, because I think I may have deleted, so there's nothing in this Chef server. We'll create one. But the idea behind this thing is that we want to actually begin with this series of exercises next time, which will help us understand how do you use Chef client and Chef server together. So this is the Chef server, Chef client exercises starting up. So we need to have a Chef server. So we are going to rent one for right now, rent for $0. It comes with a limit. The limit is you can manage only five nodes, meaning five machines for free. That's a free limit. But for our usage, this is good enough, at least for now, for this exercise, good enough. So we'll use this. It is free. You might actually exceed it a little bit, six or seven, and that's OK. It's not going to hurt. They don't cost you money because you don't give them a credit card. So there's no question. But they might send you an email saying, hey, it looks like you exceeded. And so if you tell them that you're taking part in the boot camp, they'll say, OK, fine. And they'll basically go away. They'll not ask you to pay for it or anything. So nothing like that. Just tell them you're learning and trying to figure out what this thing is. They'll go away. And subsequently, in another exercise, we'll create our own Chef server without any limitations. And that is also available somewhere down in this chain. So we'll do that exercise also. And that is going to be your own Chef server, your Chef server. And that means no limits. It is limited by the money you have, honestly. And so you have to spend money for that Chef server because you have to actually get a box in place. And so that box will be like a 4 GB RAM, at least. That's a necessary requirement for the box. So you don't have to keep the server running all the time. But just you can set it up, figure it out, use it for a day or two, get rid of it. And that will cost you maybe a 10 cent, 5 cent, something like that, some small amount, which is probably covered by your coupons. So it's no big deal. So that's the exercise for the next step. The preparation for that is that you need to create an account with this company, which will basically give you access to their Chef server, which you will be using in the next exercise starting Monday. And with that, I will stop recording. And I am still here for questions if you need.