Hey guys, we are recording this session. Can you see me? Hey. There he is. And another video. Here we go. So two video cameras, three or a few lines in me and we are recording. So there was a question already that was asked and I'm going to ask that question. The question was about gem files and bug files and all these files and what do they do? And so the succinct answer to that, gem file. And they will, you know, there's another thing called Burks file. And by the way, there will be files like that across along the way and there will be a tool that will look at that file and will do the setup installation part. That tool is called Bundle here. This tool is called Burkshell. And like that, there will be another file, for example, called Chef file. And this tool is called Librarian. And so like this, there will be more tools like Docker file, for example, and like that there will be files and files of different types and the tool will be Docker and the output of this will be gems installed. The output of this will be cookbooks installed. The output of will be cookbooks installed. The output of it can be a variety of things like you can get a build created or other things, some variations you can see, but a build of an image, a container image. You can build that image is the output that you will receive when you have a Docker file and you run Docker build command. The output will be built. An image will be the output, I should just say image. That's a better way to write it. So you will get an image. And this image you can use to run a container later on. So these files, four different examples, they're very similar. These two are very similar. They're actually conceptually identical. They get cookbooks. You also get cookbooks. So it's the same thing, whereas what is a gem? Gem is a Ruby program. What is a cookbook? It's a collection of recipes and the same here. What is an image? An image is something that you run a container out of using an image. And that's the descriptive way of describing these four different types of files. So now I'll ask you a question again. OK, so is there any time when we would want to run Chef to build up an environment where we would use a gem file instead of a Burke shelf? And actually, I guess what you pointed out is you define the Chef using cookbooks. And that's what actually builds the environment. Yes. Yes. Yes. Yes. These are readymade pieces of software, Ruby programs that will be, so for example, Bundle is a gem, Burke shelf is a gem, Librarian is a gem. These are Ruby programs. Right? So how do you get Librarian, how do you get Burke shelf, how do you get Bundle? You say gem install Bundler and then you get Bundle. You say gem install Burke shelf to receive the Burke's command, which is a part of Burke shelf. And then you run gem install Librarian and dash Chef to install the Librarian command. So they're basically executable programs written in Ruby, which are called gems. Like in Windows, you compile a program and call it an exe file, and that is an executable. These are executables. They're Ruby programs, they are available here. In this website, you can download any Ruby gem you like. As long as it is available, you can see that there is Burke shelf. Right there. Similarly, there is this thing called Librarian. Right there. And also Bundler, right there. And that's how the idea behind these three types, one, two, three examples, all three are Ruby programs. You can install them with a gem command. Gem install this, gem install that, except Docker is not a Ruby program. It is a Go language program. So you have to install Go language, definitely. It is not a Ruby program. So the gem concept doesn't apply. Ruby has this idea of gems. Go is a different language. And so you install Docker by saying something like go, get something, something, and it will get the Go program. In our example, it can be Docker program. So if you go back to here and say GitHub, GitHub, and then Docker, and then find out the Docker source code, you will find that the Docker is actually a program written in Go language. Right there up front. It's Go language based. And this is the source code for Docker. And you can see how to build the Docker binary itself. They describe it somewhere along the way. You will find how to build Docker probably in a wiki or something. Under the hood, it is C groups, namespaces. We talked about the C groups a little bit, right? We talked about isolation. We'll do more Docker, by the way. Docker is the way to go forward. So we'll do more Docker in the third segment. Namespaces has an isolation, again, and creating limitations around what can happen within the context of a container. And then the layer file system, the underlying nuts and bolts are written in the Go programming language. There is an image specification. That's what a Docker image basically means. There is a container specification. That's how you design containers. Then there is a build available for Linux, a build available for experimental, build for Linux, a build for Windows, a build for FreeBSD. And these days, a build for Mac, and so a variety of solutions available using the Docker source code. This is the source code for Docker written in Go language. It is not Ruby, so there is no gem. There is Go package. OK. Yeah, because one of the steps was to load MySQL. And it seemed like there were a couple of different... We could have used a gem file to load MySQL, or putting the entry in the Birx file or bookshelf. Let's go see what can be done about that. So here is Boot Camp, DevOps, and let's log in. I think I may not be logged in, so I'm going to log in right now. Log in. Yeah, the solution was to use the Birx file. Yeah. There are multiple ways of doing things, and so we will understand what those ways are and how many of those do we have to use and can we use other ways. And so that's what I would like to focus on and answer your questions if you have it. And DevOps, and the exercise was solution to the exercise. And here, we are saying that, you know what, you go to the Birx shelf, Birx file, and then add this line. The idea behind this was that you tell Birx command that I want to get the MySQL codebook, so please get it for me. So I will specify MySQL listing in here, in the Birx file, and then I will run Birx shelf. And then I do that, Birx command will look at what you specify in the Birx file and get the codebook you desire, and it will place that in appropriate location so that you can then use this codebook to implement your desire in a configuration, in a machine configuration. Right? Yep. And it works. Okay. Beautiful. Let's keep going. So we did this exercise, I think I demonstrated the last time, so I don't want to repeat it unless you want it to quickly, you know, repeat that exercise, we can do that. I have no problem repeating anything if you like, but we also did, I think we did further ahead of that. Yeah. Oh, we are way ahead of this MySQL thing. So we were doing this exercise and I succeeded in starting a machine using KNIFE. I remember that. And I tend to forget what I covered because, yeah, so I remember that we did this kind of sort of like around a starter codebook and starter role. So let's see what was done back here in the terminal. Let's see if we have a Chef repo. Yes, we do. Let's open the atom editor so we can see what was the last command run. And I think we ran the starter role and we saw this name popping up in the log file. I think we did that the last time and then we kind of ran out of time. And so this exercise, I think we completed, correct me if I'm wrong or if I'm not remembering it right. Yeah, we saw the entry in the log file as it was generating or starting the crash. Yeah. So as a consequence, I would like to then recap what we did the other day. Just my microphone a little bit. So we have two Raj, Raj iPhone and Raj K. Okay, so I think the microphone is not working for Raj or something like that. But no issues there. You can join from multiple locations. That is totally possible. And I am not running Slack chat for some reason, which I should and Slack opens up. Okay, Shiv has a question apparently. Okay, so Shiv has a question about getting a little confused as to the need for configuration management tools like Chef, when we can run applications on containers and eliminate a layer of complexity in the DevOps pipeline. Can't our desires be all addressed by Docker? Yes, you can. You're actually right. That is happening, by the way. It is happening like that, where people are getting attracted towards more and more towards containers. So much so that you can see some examples like this. I think you have heard me say that Google runs. Yeah. Also, I think I read Ansible is having a Docker. I cannot hear you clearly. Cannot hear you. I also read somewhere that Ansible is also having Docker plugins introduced. Yes. I mean, you can have direct access to... Yes. Correct. So this trend of using Docker has been growing a little bit. And here is an example, a new story that says everything at Google runs in containers. And the example is in 2014 or something, two billion times a week is how many containers are started at Google. That is quite a big number, but it's Google company. And so that was expected. But this is old news. So the usage of containers has gone tremendously crazy. The number of containers people are running these days is enormous. And it is actually the recommended way of using. If you go look at even cloud genius number of containers that we run to run this website is actually big. Let's see if we can get to the right point. You can see and count the number of containers that are active right now. And here we are. So how many do we have? Let's count. So we got one, two, three, four, five, six, seven, eight, nine, 10, 11, 12, 13, 14, 15 containers running. 15 containers in not running, not all of them running, but a little bit less, like one, two, three, four, five, six, seven, eight, nine, 10, 11, 12, 13 containers currently active to run this site. Where is that site? Not this, not this, not this, this site. This site we are looking at is running in 13 different containers. It's a small site, you know, small company. So yes, I use parts of Ansible, but most of it is Docker to run this service. And that is the trend. If people are using containers more and more, no doubt about it. No doubt about it. And yes, we should use containers to the extent we can when it comes to containers. Sometimes certain things may not work. For example, Microsoft Windows. But then even Windows has built its own solution. You can see that solution if I can. Hold on. Let me see if I can connect to it. So I'm trying to connect to, oh, not this picture. I'm getting connected to the remote desktop. And remote, no, why the same picture pops up again? Hold on. There has to be a way to find that remote desktop thing. There we go. And here, if I run this, I can probably show you Windows Docker if it lets me, if it lets me connect. And so, okay, it did. So I'm going to show Windows Docker right now. And you can see that a new version of Docker is available. And so I will install it later. But for right now, if I just run CMD on a Windows machine, you can see that this thing has a Docker image, which is a big image size. But it is running Microsoft Windows Server Core, just like you would see in a Linux machine. This is using Windows containers and is running Windows containers. I'm going to run a Windows container right now. So Docker PS-A will have some old examples that are exited, exited. So those things are, this thing is still running apparently. So I need to go kill them up. So Docker RM-F, Docker PS-A. Oh, I don't know the commands in Windows by hand. But maybe I'll just ignore all of this and run one more container. So there are slight variations in the commands you type in Windows versus Linux. Yeah, it will not let me. But yeah, forget that. So I'm going to run a Windows container, very, very simply Docker, run, and then the name of the container, dash IT, followed by the name of the container like this. So it's Microsoft Windows Server Core. And then you execute the PowerShell binary in there, as opposed to bash. And so it is unable to find this because I typed it wrong or something. Windows, Windows, OK, is it Windows Server? The S is missing apparently here, S. So I need to type it properly and say Windows Server Core. And now it will run a new container, which will execute in a container infrastructure on a Windows machine like this and will invoke the just enough operating system known as Windows Server Core and will execute PowerShell command in there. So here is Windows Server Core, which is the OS, the just enough small, tiny little OS. And this will run in a container, in a Windows container, meaning it cannot run Linux containers. But the limitation here, if you right click and say, switch to Linux containers, then it will become Linux only. But for right now, it has been switched over to run Docker containers using Windows as the foundation. And you see that it is taking so much time to even start a container, which is pathetically horrible, but it did finally succeed in starting a new PowerShell command in that window. You see that I ran Docker run something using Windows Core as the foundation and execute PowerShell in there. So I get my PowerShell prompt. This prompt is the prompt containing all the things inside that container, as opposed to this prompt. As opposed to, let's go to a CMD again. How do you open CMD again? Okay, right click and Command Prompt. And so this is the window on the right side, is the window for the machine itself. Whereas this is the PowerShell window inside the Docker container running Windows Server. And you can see the differences, pretty much. There is this license.txt file, which is what the Windows Server Core is containing. So I can read that license and operate on and run my own independent standalone isolated environment inside the Windows container running Windows Server Core as the OS. And one more thing you should actually find is this thing that I mentioned somewhere here on Facebook. I mentioned, where is that here? So I say, Microsoft Windows Server Core is a, come on, come on, where is Microsoft Windows Server Core? There. Microsoft Server Core is in 4 gigabytes. So people come and talk about it. Is that just the kernel? It is still pretty big. So I say, what do you expect? One megabyte Alpine? And that was just a comment on, you know, 4 GB is too big for a container. But I guess that's the minimum Microsoft could actually reach. And so they have tried to shrink it down to all the way 4.07 gigabytes. That's the concept of the juice, right? Yeah, this is their juice. I mean, come on. And so the juice should be like a megabyte. You can see those things in, you know, you can very, very, let's skip the Windows part. Let's go back here. So the second, then once, you know, this question pops up, the second part, then it also comes up like, okay, but don't you then need certain things to be set on the host before you actually run the containers? For example, opening up the AT port or the HTTPS port or the running web server, doesn't it need the ports to be opened or then can the container actually interact with the application? So I would like to clarify your question so that everybody understands clearly. And I would also like to understand what you're asking is that if you have something inside a container, so this is your container, say for example, container, and you want to run your applications inside the container, right? This is your machine under foundation machine. And you want to do what again? Opening ports. Opening, for example, we install a web server and open port 80. Right. So the web server will run here on port number 80, but you cannot access that it is isolated. People are asking, but doesn't the port 80 on the host, for example, on the VM host needs to be opened and only then can you actually bind it to the container? Correct. You have to open port number 80 here and then map it like this. Right. So to set all these states, don't you need these config management tools to actually do all the necessary configurations on the host and then only the containers can actually run properly? Yes. Yes, you're right. I mean, you need some tool to do the configuration management, right? And so that I mean, then that means they still play an important role in the whole DevOps pipeline, right? You can skip that. Yes and no. Yes and no. Yes. Yes, you're right. Yes, you're right. They're useful. But then Dockerfile also does some of that Dockerfile can do this port mapping itself right there. So you don't need these guys, honestly. If you're doing just in the containers land, you don't need to use Chef or Ansible. But then you can actually mix and match these tools according to what your desire is. And that's the reason why people are using a variety of these tools is to fine tune exactly what they want to accomplish. But to your simple example, mapping port number 80 on the machine to the port number 80 inside container running this application. You can just do a Dockerfile mapping, port mapping is done something like, let's see that example here. But that means it can interact with the host outside the container also. Yes. Yes. Yes. Outside. This is in the container inside. Okay. Totally. You can any to any mapping. You can have some random XYZ numbers are one, two, three, port number one, two, three, you map it to port number 80. That also works totally any to any mapping outside to inside. You can do that mapping using Dockerfile just like I described here in the other example like Dockerfile. I understand the mapping part, but how do you make sure that how do you actually open up port 80 on the VM post? I mean, yes, now you're making sense. Yes, you're right. You will need some tool. And so on the physical machine, like this is the actual box. You want to open this port in this location, right? That port number 80 you want to open, you would need something like fundamental tool like a shell script, for example, or Ansible tooling, or some chef cookbook. For example, the cookbook I would use is called IP tables. And this IP tables is a ready-made cookbook available that will basically help us manage the firewall on this machine. And you're absolutely right, Dockerfile will not be able to do that. Dockerfile is basically designed to manage your containers themselves here, not this. It cannot mess around with it. So you need some external tool to manage the firewall rules. You can do it through shell script, Ansible script, chef script, God knows other things, a variety of ways of accomplishing this idea of opening this port, you can. Not Dockerfile. You're right. Yes. So right now, Docker and microservices, it looks like the combination to go, right? I mean, to run all the applications. Yes, indeed. And so you have a get Cloudify link that you have posted. I think it would be a good idea to just paste that link in the group chat to help everybody also get your questions. Probably when it's a group time, probably if you can also talk about OpenStack and the emergence of OpenStack, that would be also great. Yes. Yes. Yes. So there is another question here on, this question is old question, I guess, tried web to others. So question is old. So from previous time. So let us continue our journey here, not Facebook, but yeah. In here, what we did the last time, I was going to recap what we did last time, right? So the recap was basically we rented a chef server. And we rented this from this company called chef.io. And we sat right here in our workstation. In that workstation, we created a kitchen. How did we create a kitchen? We actually said, you know, you please give us a readymade kitchen. So we got that kitchen from here. We called it starter kit. This readymade kitchen, they provided to us. We modified that kitchen, made some changes. We, you know, a little bit changes that our credentials in the knife configuration file. This was the most critical part in our exercise. If you remember our knife configuration last time, add knife plugin. So the knife configuration looked something like, yeah, two more steps back, I think. So the most critical part was to make sure that our knife RB file is correct. The critical elements were the node name, client key, chef server URL, these things that are here. You know, the node name, client key, chef server URL, cookbook path with reference to site cookbooks first before the other cookbook folder. So we did that. We also did the other segment, which is, you know, connect me to my Amazon cloud, connect me to my Digital Ocean cloud, connect me to my some other cloud. You can go on and on like this add cloud configurations, add cloud credentials in here. And when you have those credentials handy, then your connectivity between your workstation, so your workstation again here, and this is you. You are able to connect to the chef server. You can verify that you are able to successfully operate on. You can send a cookbook, send a role, send whatever you want, send your desire. And that desire is kept in this location. Now that you have established your connectivity to the chef server, you will also want to establish and make sure that you are able to connect to the Amazon cloud, to the Digital Ocean cloud like that, and to some of the clouds you might have. And you verify that by running specific commands like knife ec2 server list here, show me all my servers in this cloud knife ec2 Google list in the Google cloud knife ec9 knife Google server list. I should say knife Google server list for the Google cloud knife as your server list for the Azure cloud like that. And knife Digital Ocean droplet list for the Digital Ocean cloud. They have a different way of calling the machines. They call it droplet. So we just change our command. That's where you are able to understand that you can interface with that particular cloud. And as a security precaution, what I have done in the after the session yesterday, the other day is to delete my token and delete my access key and secret key. They're all destroyed because of security reasons. So in order for me to proceed further, I need to generate a new token and put that in the place of this token. Otherwise it will not work. So I'll go to the API section, create a new token and generate a token. And then take that token, copy it like that, and put it in the right spot. Otherwise my DO will not work because I basically destroy the tokens that I create. So at this moment, my connectivity between my machine here and the Digital Ocean cloud should be functional. How do you verify that bundle? Brutal exec and the Naive Digital Ocean server list. But by the way, the name server is not correct in Digital Ocean. So I should use the name droplet. And then I will see my list of droplets, which is empty, but it will connect and respond back saying that, hey, you don't have any droplets, which is totally expected. And I don't have any. Similarly, in the Amazon cloud, I have also made sure that I delete my key pair, these are dead. So I should go and get a new set of key pairs. I can proceed forward. Before without that, I cannot actually operate. So I need to generate a key pair because I basically delete my key pairs as soon as the class is over, a session is over. I upload my video to YouTube and delete my key pairs. Otherwise somebody would exploit, people can see it on YouTube, right? So somebody will exploit my account. And with that security precaution I take is I just go and delete my security credentials. And so right now I need to go and create them just like that and say, show it to me, copy that. Put it in place of this one. And then get the secret access key, copy that, and put it in place of this one, pretty much like this. So now I have my secret in place and I can close this and I can go back to my terminal and then verify bundle exec. Instead of DigitalOcean, I want to make sure that I want to test my connection to the Amazon Cloud. And I will say, show me the list of my servers. And it will tell me the list of my servers successfully. It is currently empty. It will also make sure to go to the right, the correct chosen Ohio region, because that's my region of choice. So this lets me connect to the Amazon Cloud. This lets me connect to the DigitalOcean Cloud. And these things let me connect to the Chef server. I have made sure that I am able to connect to the two clouds, but have I checked my connection to the Chef server? Bundle exec, knife, cookbook, list. Let's see, do I have my cookbooks in there? And yeah, I do. My starter cookbook is there. So I can test my connections and it seems to work. Having done that part, what I want to be able to do is extend this desire that I have. My desire last time was to run the starter cookbook, which is kind of pretty lame. All it does is a log entry. So you can see that this log entry has this name, which is my name, and it basically overrides the name that is defined in the attribute here called starter name. And so that default attribute name is Sam Doe. So I remove that name, put my name in there because of this override attribute. And then I run and then when I run it, I see that the log entry is there, but this is kind of boring. I mean, why do I want to see my name? And so I will delete that role and I'll delete the cookbook as well. That's boring. I mean, it's literally starter example and this Chef ignore, we can also ignore for right now. So we have empty cookbooks, empty roles, empty side cookbooks, basically we have nothing right now. So now we want to get something interesting. So this is a deviation. It is not written down probably, but let me just quickly check if something is actually written down. I think we are talking about uploading the kitchen and then running the command itself. Come on, next unit. Start a machine and the next unit, cheat sheet can be, you know, cheat sheet is just a cheat sheet. You can just refer to it. And by the way, there is a video walkthrough. And so this video walkthrough is pre-recorded and it is probably two hour, 13 minutes long. And so don't have to play it, but this is probably the most intense exercise that we are about to begin working with right now. If in this DevOps segment, if you do just one exercise, let me tell you this is the exercise you should do, right? If you do one thing and do this one, you know, skip everything else if you have not done. And if you want to rewind and repeat something, there is a little video already available to you right here. It's a, it takes me two hours, 13 minutes. Just remember it is a long exercise. It takes me two hours and 13 minutes. Let me tell you, it will take you four hours at least, you know, give and take, give and take. So at one sitting, find a slot of three to four hours and sit and be meticulous in following along. It will work. It will give you a complete comprehensive view of what the heck are we doing end to end application deployment for a real cloud service in the cloud, a cloud of your choice. I mean, you choose your cloud and you will be able to run it. There are three examples in that video and in the write up and we will do it live with you right now. I will do that. It takes me two and a half hours because I am describing everything along the way, along the way as in as I do it, just like I do it here. It's basically recording from a previous session that I did on demand on. And that's why this, this video is available. You can see that, but I'm not playing that video right now, I'll do live. But before we begin, let us understand what that exercise itself entails. So the idea behind this exercise is Nilesh, which unit is this video in? I will, I will tell you the module number eight. I will also paste a link for you if you don't find it. But the idea here is to deploy a complete application. It's stack of dependencies and basically every single thing you need in some cloud of your choice. We have taken three examples, three clouds, you know, and we'll deploy them as your cloud on digital ocean cloud and Amazon cloud. Three examples are available here. You can pick and choose your cloud and take one complete application and let it go live end to end with one command. By the way, the key is you run one command, boom, it will be a big command, complex multi-line command and you run it and that command should do every single thing that you expect. Every single thing to take a complete web service live. That's this exercise. So let's specify what do we desire. What is our desire? Our desire is to run for this customer a complete service on some cloud and let that service be created and operated and maintained by using Chef in our workstation where we will run the knife command, which in turn will invoke Chef here. Start machines, establish things, establish that and we will have our desire constructed in form of a kitchen. We will write things down specifically and then upload our kitchen to the Chef server and then, you know, use this knife tool, which will run Chef here and do whatever it takes and you know, when I say run Chef here, if there is no machine in there, it will create a machine and then run Chef on the machine and then, you know, implement our desire end to end and make this customer happy. That's the goal. What is that application that I want to run? I want to run this application, which is open source. It's called WordPress. This is what is also WordPress. This cloud genius site is also WordPress. You may have heard of me saying that WordPress runs about 60% of websites on the internet. Similar to WordPress, there is this thing called Drupal, which is what Drupal is another open source product, very similar to WordPress, and this is also popular in the White House. Runs Drupal. Or at least, I should say, what just happened? Oh, sorry. Sorry. Whitehouse.gov. Oh, man. Whitehouse.gov. Why are these small hands showing up? That was the question I had. Whitehouse.gov. What am I typing? Did they hack the White House or what? What is going on? Hold on. Is it just the White House? I don't know. I'll just go to a Google search. Okay. Okay. Oh, man. I was shocked that the White House was hacked, but no, that was my mistake. So the idea here is that this site runs Drupal, and pretty similar to Drupal and WordPress is this thing called Joomla, another open source product, and Joomla is also popular. The underlying idea behind these applications, like WordPress, like Drupal, like Joomla, is that they are content management systems, CMS. You store your content and you're able to manage it properly in that system. To run this as a website, as a service, you want to be able to meet certain requirements. The underlying requirements of the software that you have there, this WordPress software, you want to run it as a service, and so you have to understand that requirements. What are those? Who will tell us what the requirements are? So you'll go to the source code and find out WordPress.org and what are the requirements. So we will see that the documentation, where is the documentation? And here are the requirements. And so requirements are pretty much, actually, these are the requirements, PHP 7 or greater here, MySQL 5.6, database server, mod rewrite module in Apache, so there is an Apache HTTP server required, and HTTPS support is also not truly a requirement. It is a recommendation, but they're trying to enforce HTTPS all over. That's why they're saying not required, but recommended for better security. So that's the thing that we need in order for the software to run. So if you look at what that really boils down to is that it requires you to have Linux as the operating system, Apache as the web server, PHP as the language, and MySQL as the database, 5.6 version, 7.1 version, and some version, and some version. The LAMP stack, that is what it requires. And if you have this stack ready, then you can run Drupal, Joomla, a bunch of other applications, WordPress, for example. And so you can basically take this WordPress application, download it from somewhere here, like the blue button that gets you the source code for it, and you throw it on top of expand the source code and throw it on top of this stack, Linux, Apache, PHP, MySQL. And you will get something like a WordPress site up and running. That is essentially what we desire. So we have to go and implement these things. Implement as in specify in our kitchen. In our kitchen, we should say, get me Linux, get me Apache, get me PHP, get me MySQL. And then get me my WordPress. And then make sure that you write that down in the kitchen. How do you do that? To get Apache, you need to get the Apache cookbook. To get PHP, you need to get the PHP cookbook. To get MySQL, there is a MySQL cookbook. So you need three cookbooks, right, practically, to begin with. Linux, you get by the cloud company will give you Linux, so you don't need a cookbook for that. You get the machine, it comes with Linux, and you can choose the Linux you want. And the image, Amazon machine ID, or the flavor in DigitalOcean, or the operating system selection in Amazon, sorry, operating system selection in the Azure cloud, or Google's OS selection in Google cloud. Any cloud provider will let you select which operating system you want when you start a machine. And that is easy, you just select. That is this part. So we got that. Okay, we know how to create a machine running some specific chosen flavor of Linux. We understand that. But now we have to go and deal with these other three things, Apache, MySQL, PHP, and all these guys. So we have to get three cookbooks, Apache cookbook, PHP cookbook, MySQL cookbook. And so we have to get these cookbooks. So what do we do? We do write that down in a marks file, right? Pretty much like this. And so instead of creating a, I think I created it in the wrong location apparently. So I need to go close this, close this, and I need to create a, this chef file, I should create it here. So I should create a file called chef file, just like Burke's file. I'm just using a different example now. And what I'm going to do is follow along in our write up so it doesn't confuse you. So in this write up, you will see that, you know, we have our, our knife RB constructed pretty much like what we did already in the previous step. And then the next step that we want to be able to do is get to this chef file. But before chef file, I think I'm jumping a little bit ahead after the chef file. So let me not jump and stick to what the write up is because this is a long exercise and I don't want to confuse anybody. So I would like to say that sticking to the sequence written down in the site, the next idea that we are discussing is to specify a gem file and call out very specific versions of gems that we would like to use. And by the way, you will see that this gem file is a very long file, really, really long. And I'm going to great depth in calling out all these gems that I need by name and by version number. And I'm going to copy all of that. But this gem file is what needs to be replacing this whole thing. So that gem file, the old one we have goes away. And instead, I put this long gem file with 162 gems. Why do I have to go so elaborate and how do I come up with this list of gems that I need? The answer to that is through practice, through experience, I know that these are the gems that work well with each other to accomplish our goal. And it is through experience that I have accumulated specific version numbers of a variety of gems, 162 of them, 162. At the very top, there is this line called actually 161 gems. At the very top, this line called the source where the gems come from and the reference to the Ruby language version that we are using and then a list of all the gems on alphabetical order that includes the gem for Chef, the gem for DigitalOcean, where is that, Knife plugin, KKK should have. So let's go search DigitalOcean. And so here is Knife DigitalOcean, here is Knife Azure, here is Knife EC2, here is Knife Windows. So you have these various gem plugins written down in the long gem file, which is here. And this lock is old, so I want to get rid of it and move it to trash. But remember that this gem file can be extensively long. There is a reason why we have to have it like that. And the simple reason is written down right here. Enforcing version discipline with a gem file. What happens is in a large project, you have multiple people working with a variety of things and they will say that my version number for this is slightly different from your version number and it will cause complexity, cause confusion, things may not work. This works on my machine, it doesn't work on your machine and you want to cut all that down. You want to bring the entire team in one way of operations, unified, consistent across the gigantic organization you might have. And you can ensure that discipline by writing things down succinctly. And so this is one way of enforcing that discipline is to make sure that everybody is using these versions of gems and nothing else. And that is why this gem listing is so long. It is more elaborate than any other example you saw before. We had like four listings, five listings, this and that. This was exhaustive, 161. So now we close the gem file and we go to the terminal and say, you know, let's list out what we have. So we have that thing that we see when we get a folder called cookbooks, a folder called side cookbooks, both of them are empty, a folder called roles and a gem file. Now you would see that there are some hidden elements here. So you can see that the hidden elements are in the dot chef folder where we have my configuration kept, private key to the connection to the chef server. This is an empty folder, empty folder, empty folder. The gem file contains a long list of 161 gems and a getignore file. Nilesh, how do we beat the experience part? Because when we want to implement a new desire, how do we actually, I'm sure everybody is like stumped here, like how do we go about, is there any way automating that or how do you, because this seems to be very inhumane, I mean, right? I mean, how do you come up with all those versions? I know, I know. So this is a reflection of the end result. You don't come up with this like magically overnight. You come up with this by iterating on a test scenario of implementing something very small, very simple. For example, if I want to begin something like a new project, I will not have a 161 long list of version numbers magically out of thin air. I cannot. What will I do? I will actually have just three or four listings. What will I have? I will say, you know, I need these books. So MySQL, PHP, Apache. That's what I really require. So I'll go to the cookbooks and say, how do I need these, how do I get these books? I need some tool to download those books. What is that tool? Oh, it's Berkshelf. Huh? Okay. So then add Berkshelf to my gem file. So I'll have just Berkshelf. And that's it. Then I will run it. Bundle install. It will get me the Berkshelf gem. Then I will put a Berks file for three book names, MySQL, PHP, Apache, and run. When I run, I will see that it has some dependent gems that are also pulled down. I can see my gem list. And the gem list will actually show me what gems do I have installed. If I just installed one gem, the Berkshelf gem, it will give me a list of all the other gems. Pretty much like this. And here you will see that all the gems that I have actually run the whole thing multiple times. I have a lot more gems. But as you begin working on, you will have a smaller list of gems. You will take a note. Oh, it requires buff shell out 020. I see. It requires builder 323, bundler 136. Oh, I make a note of these things. And what I'm really doing is locking down the exact versions that I seem to have right now. And I iterate upon. And I will fail along the way 100 times, maybe more. More number of times I will fail because I will begin to build my collection of gems and write that down succinctly. When I begin doing this thing, I will probably have one gem, maybe Librarian. And maybe a couple more, like bundler, for example, the original bundler tool. And I'll have a reference to the Ruby language. So I'll begin with a very small collection. But I will see that it will bring down other dependent gems. And sometimes I will see that there are failures occurring. So I'll have to go and adjust the version numbers accordingly to make sure that there are no failure happening. When I notice that there are no failures happening, I will take a note of all these versions and gems, write that down in a plain text file, and then delete all the gems I have. Uninstall every single gem I have. Then take my list, the text file that I have, put that in a gem file, and run bundle one more time. This time I will cut down on these duplicate numbers. I have this version, this version, this version, and this version. Four versions of Chef are installed on the machine right now. I may not want all these versions. I just want the one that I know works. So I want to cut everything down and put whatever I need in that gem file, clean all the gems, bundle install again. And then I will have just one version of that gem, one specific version of this gem. Not three versions of Chef 0, but just one version that I really, really want. And I'll run again and see if there's some failures or see if the things work out or not. That's how I will start building and accumulating this long list. So it took me a couple of months to actually get to this point long, long, long ago. And I keep, even today, even I think two days ago, I actually modified this gem file. I made a change here. The change I made was Ruby 2.3.3 as opposed to Ruby 2.3.1, the new virtual machine has 2.3.3. So I had to make that change. And then I bundled it. Basically, I ran a bundle install to make sure it works correctly. And it did. So I'm happy about that. You will also see, if you remember, I don't think you do, but if you had seen this exercise before, there's one more change I made, which was regarding bundler. So this bundler tool, this bundler was 1.13.1 in the exercise just two days ago. And I came in here and I modified this line here, 1.13.6. So now it says 1.13.6 as opposed to just two days ago, it was 1.13.1. Why did I do that? Because bundler changed. The machine changed. So I had to go and update my bundler version. Now I edit the website also so that you can just copy and paste. And then when you copy and paste, you get this gem file in your listing to be specific, this gem file. And then all you need to do is run bundle. And it will create all the things you need magically. And it will work. It will work very fast and very quickly for me. And it just finished. But let me tell you, this action will take about 10 minutes because I have already done it. So it just finished quickly. But if you attempt to do that, it will take you 10 minutes, roughly 5 to 10 minutes, depending on how big the machine that you have. Another thing I would like to caution you is this action will fail if you do not have patience. If you get frustrated, it will fail on you because you'll tend to break it by pressing something or just get impatient. Another thing, you will find that a couple of these gems will take a really, really long time. One of them is this thing called... Here, let's go show... Neela's question. Yes. So let's say if I'm starting off and I'm only using AWS, my gem file doesn't have to be this long. Correct. You're right. This gem file is artificially long because I have made it run in three different clouds. OK. It is unnaturally long, but it is more of a classroom example to show that you can run it in multiple clouds. In real life, you'll run it with one cloud, maybe two, not three. This runs in three. That's why it's slightly longer. Just two years ago, this file used to contain 56 or 60 gems. Now it is 161. How did it grow? Simply, I added one more cloud. It came with a new gem called Knife Azure, like this one, Azure. This gem I added, Knife Azure gem, and so it came with its own dependencies. I captured those dependencies, also put that in the same gem file, cleaned up all my gems, ran bundle install one more time. How do you clean gems? Neela's question. So if I'm only going to use AWS, which of these lines should I pick? How do I know that? You will pick only this line to begin with and see what happens. If you have other dependent lines, it will come up and get installed. So when you run gem install Knife EC2, let's go see that. I'll tell you how to find that out. So you go to Knife EC2, the website on GitHub, right there, and it will tell you what are the other gems needed. So here is the gem file, and so it requires read line. This gem is required, so you will get read line gem as a consequence. You will find that it will have some dependencies called out, and those will come along the way as you just begin with one reference in your gem file, like this. And you will not even put the version number, by the way. I'm putting version number here because I want to enforce disciplines. I'm using 0, 12, 0. In here, in GitHub, they're saying, don't even put version numbers. Just say Knife EC2. Begin like that. And the actual version number may be a little bit newer than 0, 12, 0. This one is the one I'm using. The current version available is 0, 14, 0, so updates happen. So I can take this one if I like, but I'm not ready for that right now because I don't want to mess up this exercise. But if I'm doing a separate exercise, I'll probably use this gem, 0, 14, 0 release, which was released on December 2nd last year. I'll probably use this. And so currently in the exercise, we are using this slightly older version, 12, 0, and that was released in 2015. That will also work. Nothing wrong with using a slightly older version. It's just that we are not, this exercise is not set up with this latest version of gem because if I go that direction, I will have to change a whole lot of other gems that will fluctuate a little bit. And then I don't want to do these things with you in a classroom. I can do that totally, but I don't want you to be watching me messing around with gems. It will confuse all of you and you will start hating me basically. I don't want that to happen. So that's why we give you a specific clean approach towards getting something executed to get you what I call instant gratification. And I should actually not call it instant gratification because it takes like four hours and then you get the gratification. So it's four hour delayed gratification, but better than two months though. Sorry. Better than two months. Yes. Yes. So that's why we go to the extent of locking down specific questions like this to minimize churn on you. But Ilyush, again, I'll question on referring back to Raj's question. Why do we say EC2 knife, wouldn't we say EC2 chef and that'll get the dependencies off the chef version for knife and all this stuff? So the gem name is knife EC2. So you use the, I saw that you also use a chef also there, right? The gem file. Where? In the gem file? Yes. In this file? What do you want to search on? So the chef, the gem chef something, I think I saw that or yeah. So the chef gems, chef, chef config, chef zero, they're not tied to a cloud. Okay. They're not cloud specific. They're the chef source code or chef gems, chef, chef config, chef zero. And so there are other EC2 specific is only one, this one. Got it. Okay. Ocean specific is only this one, right? Azure specific, they're probably more. So you have managed compute, network, resources, storage, four gems here plus one more, I think two more. There is the one, two, three, four gems here plus the knife as your plugin, the plugs into the knife configuration. This knife tool basically, as you know, if you know knife and I run knife command, what this does is a remote execution of chef here. Chef will run here. But what is that here? It has to be a machine. And what if the machine doesn't exist, where will chef run? And that's where knife plugin comes into play. Knife Azure. What this will do is it will have your credentials for Azure. And if the machine doesn't exist, and if you say knife Azure server create, it will create a new machine here. And then you have a machine. And then you will run chef. So the idea essentially is to be able to create a machine in some cloud using the credentials of that cloud. You get a machine and then you run install and run chef. We did this example, we were here, we said knife EC2 server create. And we had our knife EC2 plugin. And this plugin, we also given our AWS credentials. So then it knows how to create a machine in the Amazon cloud. So it will go and create a box there first T2 micro. And in that box, it will install chef and then run chef. And when it runs, it will go to the chef server, download your kitchen, and then implement your desire and make you happy. That's the end to end game. Without these credentials in place, this plugin cannot really create a machine. So you need to be able to create a machine, delete a machine, run this, run that, make your desire successful. And therefore, you need those plugins that will allow a cloud company like EC2 to operate using the knife tooling. And that's where you need those credentials here. You see them that I'm putting credentials here in this location like that. And similarly, for knife DigitalOcean, the token like that. This is the plugin, DigitalOcean plugin that allows me to operate on the DO cloud pretty much like this. It is going to the cloud DigitalOcean and saying, hey, give me my machines. What do I got? Oh, you got nothing. Here is an empty list. So you get the empty list. Now you try the same thing. Go break the token a little bit and say, token is broken. Save. Close. And now come and run the same command. What happens? Failure. Why? The token is broken, unauthorized. Go back. Fix your token. Fixed. Save. Close. Run again. It will work. Why? The token is valid. You can do the same thing with other clouds, Amazon cloud, token, broken, save. Go back here. It will say access denied or something like that. It says unknown region. Some random error. The idea is it could not figure out what to do. The error message can be cryptic. But fix the token. And then run again. It will, uh-oh, uh-oh. What just happened? Unknown region EC2 US East. OK. I think what has happened is this region that you have, AWS region, Ohio region is new, like two months old. So we should not be using Ohio region with a collection of gems that doesn't understand the Ohio region. This Naive EC2 plugin that we have, the version that we have, doesn't know that there is this US East 2 exists. It doesn't know. Because it's new. The plugin is version one, version zero, 12, two, whatever the version number is. This version number we have here is a little bit old. This version is old from 2015. You saw me show that right here. Click, click, click, click. 15. It is from 2015. So it is old. So it doesn't know that there is this region called Ohio. When was Ohio created? Two months ago. So I should switch my region and stick to the older regions that I know have and exist, which means Ohio, I'm not using you. I'm going to Virginia. What is Virginia called? It is called East 1. So I'll change it, save it, close it. And in here, I just modified that US East 1. And you will see that this thing now works. It tells me that you have no machines running in Virginia. It did not work with US East 2 because that region, the entire Ohio region is like two months old. The gem version that we have 0.12.2 is 2015. It doesn't know unknown region. And let's go modify the, break the token again. And you will see that there will be a different error this time. It says you have bad token or bad credentials or something like that. It says, yeah, failure, unable to validate the access, unable to validate that authentic verification. Failure happened because I broke my access, secret access key. So here we will fix it, save it, close it, run it. And you see it working again. That happened because our credentials are tied to the cloud and that this Ohio is not aware, the machine is not aware of Ohio, Ohio, it doesn't exist for it. So we'll ignore Ohio later. We'll deal with Ohio later once I update the gem version sometime. I will then include capabilities to operate on Ohio also, which is as simple as going here, looking at the gem file, identifying the EC2 result and making it 14, as simple as that basically. That's where it boils down to. But let me caution you. If I go that route, it might throw something else off a little bit. And so something else might pop up this time. I don't know. We'll play with it. I'm going to bundle now because I just updated my gem file. So I'll go bundle update. It might throw off a little things here and there. We don't know. But you will see that it installed Naive EC2, 14. It was 12. Now it is 14, 0. It was 12, 0. So bundle updated. This gem updated. OK. So bundle updated. Let's see. Nothing else. OK, good. That means we might get success. So we have modified our EC2 gem here, EC2. It is 14, 0, which is the latest today available. Now we can go and play with Naive RB, make it East 2, save, close, and run. Again. And this time, I'm betting, just a bet, don't know. But it will find out that that region is, oh, no, it doesn't know Ohio region. Even the latest version has no idea about Ohio. So that happens. People not, let's see if there is Ohio reference here. So I go search US East 2 in the repository, could not find any reference to US East 2. How about US East 1? Yes. So you see the source code doesn't have a reference to US East 2 at all, even in the latest version of the Naive plugin. The source code doesn't know Ohio exists. How do you think it will run? I just ran a search on the source code for US East 2. There are no references. US East 1. Yes, it's there, multiple places. You can see that in the source code for the gem itself, you will have these regions specified. Let's go find out where is US East 2, US East 1. And OK, come on, search, please. So it says no region was specified. The default region will be used and all that. So bottom line, this is not updated yet. And so we'll have to go and ask them, please help us in using Ohio region. We can create that by creating a new issue and ask them, please support. US East 2 and describe the concept that you want here and then send a request. This lady in Pune, India will actually go and fix it. She works on that gem. So she will fix it and she will notify you in the plugin issue that you create. Now you can do it this way, this is how collaboration works. This is what something doesn't work. You will find the root cause and go report an issue in the source code. The developers will actually come and fix it for you. That's what happens. You will see this all the time. If you find something doesn't work, you have to go root cause the problem, report an issue. The open source community will come and help you. That's what happens. That's what I just showed you that example. She will probably, she or maybe the team members will do something like this. She works for this company called Flowgenie Technologies in Pune in India and they maintain this EC2 plugin on the community. That's what they do. So a bunch of people do that. By the way, there are 49 contributors. She is one of them. There are lots of people that collectively help build this plugin and she's active. This Chirag is another person of the same company in Pune, India. So basically, I know these guys, they're managing, maintaining the gem here. Bottom line is this Ohio region, the gem is not aware of, so it will not work, which means we need to stick to using the other region like US East one and save and close. After I close it, I need to also make sure that my public key is provided to the US East one region. This public key, US East one doesn't know, so I'm going to copy it, go to the US East one region, which is the Virginia region in the EC2 segment. I will go and add my public key pretty much like this. So import key pair, I should delete that key pair to begin with, and then import key pair and provide my key pair like that and import. Now I have my key pair there. That is an important step. You don't want to miss if you change the region for some reason, like I switched from Ohio to Virginia, you remember to give them your public key as well. That is important. It will not immediately fail, but when you create a machine, it will fail at that time. And that's what I just did. Let's keep proceeding forward. So enforcing version discipline, we had a good discussion. I think I like that. I really like the questions you asked, which is very practical, very relevant as to how do you do it in real life? You're telling us to use the 161 gems, but how do I figure out what do I use? Last question, what will the developer fix in the Ruby file? I mean, what for the USC is to, what is she going to fix? They will include references to that particular region. So since it's a new region, the gem doesn't support it. They will include references so that it will know how to basically go change the API calls to that region. So you go AWS. So this tooling is available from the command line interface from Amazon. So that tool will be used. Then there is another library that is going to be used called Fog. Fog is a Ruby library for managing a bunch of different cloud providers. So that's the underlying source code that is used by these gems to operate on a bunch of providers. So here, this library will help you manage the AWS cloud, Atmos cloud, bare metal, Bluebox, Clodo, Blah, Blah, Blah, a bunch of clouds, including Linode, Joint, OpenStack, OpenBZ. So basically, this is the foundation library, which is available in the open source right here. And you can install gem install Fog. It is also a gem, by the way. This library itself is a gem. You can see in our gem list, we have Fog installed. And you can see that, oh, I did not type properly, gem list, not checklist. And you see that I'm using the Fog library version 129. So I was actually going to ask the next question, like, first we need to correct the versions first, we should know what these actually mean, right? I mean, all these. Yes. Yes. Yeah. There are sometimes fancy names. And sometimes you need to understand, no doubt about it. You need to really, really understand and practice before you get to some level of expertise. And so that is totally expected of people who really want to make use of this. You will actually study these things and make use of accordingly after you understand. No doubt about that. So having done this little change on the Amazon cloud and going back to our discipline aspect, I think you understand that detail. So we are basically enforcing version discipline. We are looking at our tree in which we have this gem file, which is a long file. The lock is created because we installed, bundled, updated that. And then one subtle change I want to go back to is that I want to go back to my gem file that I have here. This is exactly what I want to use. I've made a change a little bit, right, 14. So instead of 12, I made a change to 14. I don't want to necessarily go forward with that change. I want to stick to what I have, meaning I will use the gem file, I'll delete the whole thing and paste it one more time, save, close. I will stick to this gem file because that's what I want everybody to use in the program. So we're sticking to that, we'll delete the lock file and not making random changes. We are sticking to what we have in our writeup that basically helps everybody else. So now that we have a gem file copied from the website over here, I'll bundle. And when I bundle, it will basically install all those 163 gems, 161 gems, and they are installed. Now I will proceed forward. You will see that as a consequence, we have a gem file lock. Our other folders are all empty, which are expected. Now is the time to proceed forward. So here we go. We want to create this, so there are a bunch of steps here, basically cleaning up. So I cleaned up already most of these guys. However, I need to create some additional folders here. So I will create them in pretty much one command. You will see that I'll create a bunch of folders in our atom editor. They will all pop up as soon as I run this command. And that is what you will see, new folders created in your atom editor. So I basically created a folder for roles, environments, data bags, cookbooks. That's what just got created. And we did that using that one command that I have here. Now in our tree structure, you can see it looks like this. So we have this, this, this, and these folders are empty, gem file, lock file, and the credentials in this location, and a private key for Chef server. That's it. With that, we proceed forward. Next we want to make sure that our knife configuration is in line with what we expect. So a little bit changes here. You will see they're not necessary. They're actually cosmetic changes. And the changes are, let's go take this knife configuration as is from here. And copy all of that. And bring it to our knife configuration file in this location. Make some room at the bottom, paste it. And now let us compare line by line. What have we got? This line, we have it already at line number three. So get rid of it. This line, we have it already. Line number four, get rid of it. Log location, get rid of it. Node name, this is going to be your name, your username. In my line number six, I have my username. So I'm getting rid of this line. My client key will be your client key name. My name is already there in line number seven. I'll get rid of this. Have a URL, this organization name has to be matching your organization name. Not my name. My name is Classroom. My organization name is Classroom. You want to choose your organization name here. And so you want to get rid of this line. The cache type is not mentioned here. We can keep that line. Cache options is not mentioned here. We can keep those lines also. Shopify API certificates is true, and that doesn't exist in any other place. So we'll keep that line. So these three, I want to keep these three down. They're not there to begin with. So I keep them from here, move it all the way in this place. Cookbook path. This cookbook path, we have it already. It is in line number nine. So I will get rid of that. Then I'm adding some cosmetic changes. When I create a cookbook, which I will, I would like to have it attributed to me. So I put my name there and my email address there. So I know who created the cookbook, which we will do, by the way. We'll create cookbooks pretty soon. And so these things are basically cosmetic in nature. It will attribute those creations to you. So you can put them in something like here. Then we have our access key and secret key and all that good stuff. So we will, we already done that part. It's there in line number 19, 20, and 21. So I'm getting rid of this. The digital ocean token, we have it already taken care of in line number 24. So I'll get rid of this. Then we have Azure. So Azure can add like this. And to be specific, you have to do certain things in Azure for Azure to work correctly. You have to go and go to this website. This site to be specific and go to that site, log in with your Azure credentials. It will download something for you. And we'll get to the Azure exercises later. We'll revisit this later when we are ready to run Azure. But it is a little bit different than other clouds. Like every cloud is unique and different. The idea would be to go to that site in line number 26 and download something. It will pop up. As soon as you visit the site, it will pop something up. You want to save that credentials, publish settings, the file has to be renamed something like this. You have to use this name and place it in that location specified here. I'm going to make that location clear to you. So I'll toggle and read that. So this should be visible. Place in. Why can I not read it? Okay. You have to place it in the.chef folder, that file that gets downloaded from this location from Windows Azure. You have to save that file inside this.chef folder, by the way. You need to visit that site inside your machine in the VM, in the Firefox browser. So go log in here, get that file downloaded, rename it with this name and put it in the .chef folder. That is a critical step. You want to do that when you're ready to use Azure. And then you are basically referencing that file in the published settings reference in the Azure published settings file reference here. You also want to get a source image from Azure. And this is the image ID that I have already created for you. You have to extract this image. It's hard to obtain. And I'll walk you through how to obtain those things later when we get to that point. But this reference ID number is like Amazon machine image or like DigitalOcean image references or other cloud references. You're basically saying, give me the Ubuntu OS. In Azure cloud, you can run Linux comfortably. And we will be running Linux in the Azure cloud. In this example, that's the image ID that we'll be using. And at this moment, I will leave these lines as is. And this will be useful for our Azure connections. Then the last one. Last item we have is to uncomment this line after you have created the encryption secret. So we are leaving it commented with a hashtag, not doing anything with it as is. Just save. No changes. Close. Proceed. And now, it's a good idea to put everything that we have done in version control like that, like we are expected to do. So we can do that. However, let me tell you one thing, and this I have found through experience, is most of you get frustrated when you have too many things to do. Like you do this, do that, do this, do that. And then you don't understand and you get frustrated and you give up. I don't want you to give up. I want you to actually complete this exercise. If you're doing one exercise, this is the exercise, by the way. And so I want you to really do. And what does that boil down to? I want to cut down all frustrations that you might occasionally run into because you're doing it first time and it is complex and you have to understand and do it. To do that, I will suggest a shortcut. The shortcut is, in this example, in this specific exercise, you can conveniently skip all git commands. Just don't even bother. I'm just showing you a shortcut. By the way, this is a bad practice. You should absolutely use git every single time, like described. But I know most of you get frustrated as you go through this exercise. This is through prior experience, like, you know, it's a long one. It takes you two hours, three hours. So cut your time down by skipping git steps, like I have here, git init, git this, git that. There will be steps along the way to do certain things that you are expected to do in a proper formal project. You are expected to use git. That's why we have it there in the write-up. But the shortcut, skip git to reduce your frustration the very first time you're running this exercise. It's just a shortcut and it's only valid as you learn this thing. After that, you have to use git. In real life, you have to use git. Microsoft Windows, the entire source code is now in git. You saw that probably me talking about a couple of days ago. There is a break request. And I think it's a good idea to take that break right now. And I will initiate that break just now. But just remember, 275 gigabytes of source code from Microsoft with 3.75 million files, not lines, files, is stored in git repository these days. Windows source code in git. And that is a fact of life. Microsoft acknowledged that. You want to use git, but as a workaround in this time, in this exercise, it's okay to skip git. Totally okay. Nothing will go wrong as such as a consequence. So anytime you see a git command, you can comfortably skip. That's the bottom line. With that, I'll start a break. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay, I think we just ran out of the time. So let's proceed. I guess people are not here yet. Saturday problems. So we just keep assuming that we're going to get them anyway. Nice one more question. Yes. I know it might be a crazy question, but it's a, I mean, how do we know which one kind of, which one is better? Like, you know, which is the chef's supermarket better or the. The puppet. I don't know. What about the. Or like check which one is probably a better calculation management tool to use at that point in time we desire. So I think the question you're asking is, which is better, Chef and Symbol? Yeah, in terms of probably looking for which is better. Right? Yeah. Right. So the way to think about this, there are many ways to think about that problem. One of the ways is your way of, like my way of thinking about this problem, maybe your way, as in Shiva's way of thinking about the problem. So when Shiv thinks, this is Shiv, he's thinking about the goal. The goal can be to help a project in the company. That can be a good goal. Another goal that Shiv can have is to find something interesting to do in life, like a new challenge, a new gig, a new job, a new opportunity, new business, something. That may be another goal. So it really depends on what that person is trying to accomplish. If you're looking to find a new thing to do in life, I would not worry too much about whether this is better, or that is better, or this is better. What I will really worry about is something like this. And I'll go compare what are the trends in the marketplace and compare that for Chef. Let's see the growth in Chef opportunities. And the job seeker interest is kind of steady, but the job postings are growing. That's the percentage of matching job postings that use the word Chef. That's a good thing to look at, that you're looking at growth in the last couple of years. And that's what you see. But let's now compare this with Ansible. What do you see? A steeper growth in Ansible. Click that. Let's see Puppet. What do you see? Yeah, OK, not that steep, but Ansible is really steep. Close that. What about Docker? You see an amazing, amazing steep rise. And so let's see more. Kubernetes. What do you see? It's loading up right now. And you see an uphill climb. What is going on in 2015 and 16? Something magically happened, right? And so when I started this Cloud Genius thing a long while ago, I actually did these things, these searches myself. Those days, Kubernetes did not exist. Docker was not popular. And Ansible was not there in big time. So people were focused on Chef. And so those days, the graph for Chef looked something like this. And so I said, you know what? Opportunity. I will learn Chef. So I started learning Chef on my own. And I went to GitHub, started learning, reading the source code. That's where I began. And then I learned it on my own, built programs, and a bunch of other things happened. And then we have the boot camp constructed. And we have been running it forever since. So we have a ton of content on Chef. But over time, what I have seen is that the interest in Chef is still there. I mean, don't get me wrong, it is still there. It is still growing. But comparatively speaking, the interest in newer tools, like, for example, this one, is kind of crazy steep uphill climb in the growth patterns. Why does that happen? Because I call it the shiny object syndrome. You see something shiny. People want to pick it up. People want to play with it. And that's how you, as a person, should look at, is what is going to help you in your career? What is that goal in life that you have? You have a job right now. You want to do something better, something different, something cool, the next. So you will go that direction. And the way to search about these things is not whether this is better or that is better. But I think all of them are good. I think all of them are open source. I think you should learn all of them, honestly. It's quite a bit of challenge, by the way. You should basically learn all of them. That's my bottom line comment. But it doesn't mean that you spend all your energy in learning each one and every one of them. But instead, focus your energy in the direction you want to go, the goal. What is your individual goal? Look at that, and then take that direction. So say, for example, your goal in your company, maybe, to help a company complete a project that happens to be using babushka, like babushka, like I mentioned here. Where is babushka? Babushka. And so babushka is basically a doll that babushka. Where is babushka? Here. So this product is what you will see that you will use. If your company uses babushka, you will learn babushka. Why is that so? Because your whole company is using this. You better go learn this thing called babushka, which is what you do, which is what you should do. But the point is not really about these tools. They'll come and go, honestly. These tools will come and go tomorrow. Point is not about using these specific tools or using a specific technology, but to understand what is the goal. In this example, you want to help your company accomplish a project, so you will identify the needs of that project, and you will meet that project goals by doing whatever it takes along the way. If it takes you to learn Chef puppet, Ansible babushka, God knows what, you will learn that, and you will accomplish the goal. That is what you really do in life. And so corporate goals meet the corporation goals. Corporate says you want to learn Windows Docker containers. You better get to learn and figure out how to use Windows containers on using Docker. Even though we know that it is slow and all that pain that you saw, whatever, just deal with it. Move on. Focus on the company's goals. Accomplish them. Yes, you can complain on the side that Windows sucks and all that, but whatever. The idea is to help your company, right? Actually, my question was slightly different. In terms of running a classroom exercise or a project, eventually, all the source code only lies on Git. All these tools eventually fetch the main thing from Git. The only thing now, there is no actually point in comparing the Chef supermarket as compared to the puppet. I don't know what you call that. Manifest. They call it manifest. Puppet has manifests. Chef has cookbooks. Ansible has playbooks. And Microsoft DSC has runbooks, runbooks. And basically, all of them are written pretty nicely. I don't complain any of them, whether it's cookbook, playbook, manifests, or runbooks. They are done by professional people trying to accomplish certain good things. And more or less, all of them will work properly. And more or less, you will find that a collection of things that you want to accomplish are already done for you. You just have to go and use them from the supermarket. You get the cookbook or go to the Ansible sources and get the playbooks or Ansible Galaxy, it's called. Puppet, you get manifest created. And Microsoft will give you runbooks for you to use and things like that. So tools are available. But that is not the important thing, honestly. What is important is your individual versus company goals that you have. And you want to go address both of them. If you have a current job, you want to make sure that your company is meeting those goals that you're working on. If you want to do something next in your future career, you want to focus on that as well. And so you build your skill sets to make yourself happy in the future, for which it might require you to learn something new. And so that's what you will do. And it's really not really important as to what these things are, because it is not relevant, honestly. Yes, there are pros and cons. Like this, we'll use the Ruby language. So if you are comfortable with Ruby, you will likely use Chef. Ansible uses Python language. So if you are comfortable with Python, you are very likely using Ansible. Puppet uses a variation, a Ruby-like, like Ruby, pretty much like Ruby. Runbooks are written in PowerShell. So you are a Windows person. You will use those things. You will basically follow along your skill set and expand in that direction. But if I were you, I would learn all of them and make sure that I am comfortable with dealing with any problem that I want to solve and find the best solution for that problem. And then become an expert in one particular segment. Learn all of it, no doubt about it. But expertise needs to be in line with your goal, like whatever company goal, private goals, individual goals that you have. That's where you build your expertise. Learning doesn't mean you don't need to learn like an expert in every single aspect. That don't get me wrong. You don't have to become an expert in every single thing. You do have to understand the capabilities of each of these products and see what they will help you in accomplishing a goal. And once you narrow it down, then you spend your energy in that direction to become an expert in that domain. Because that is what is needed to succeed. Learn all of them. Explore everything. Yes. OK. Thanks. Now, one more thing, which is this module number 8 that I begin with here. And I mentioned about this video walkthrough that is available. That video walkthrough, I have tried to not digress too much about this question or that question, but stayed focused on this exercise. What does that mean? When you rewind and repeat, like I know most of you do, play back the videos and rewind them and repeat them, it is probably more efficient on your time to use this video, the one that's already there, as opposed to looking at the video recording that is happening right now. Because I'm talking about this and answering your questions, and it digresses a little bit. This video is already focused, and I made sure in that time when I ran it, an extra session. And by the way, if you want this exercise to be done one more time on an extra session, I welcome that. You want to do it, I welcome. No problem. We'll do it. Because I find that this is the one exercise, if you do, you will really, really understand, not just Chef, but the whole concept. You should do this exercise and use this video that you're looking at, the video walkthrough video, module number 8, as the playback or rewind repeat. Or people sometimes use the word binge watch. People binge. And I first time heard it like a few months ago. People are binge watching Nilesh. And I said, oh my god. But I just heard that from somebody. I just binge watched all your videos, and I said, OK. So if you want to binge watch, watch that one. It's a very short succinct focused on two hour, 13 minute long rewind repeat. That's how you go. And that is sticking to the exercise. It will have subtle changes, like 233 ruby versus 231 ruby. So slight changes. But don't let that bother you. Don't let that bother you. Let's continue. Back here, we have our knife configuration in place. We have added some folders. These are empty. We have expanded our knife configuration a little bit to extend this Azure reference. And this one last line reference that I'll come back to you at the time when we create an encryption secret. This will help us in creating encrypted data bag that will create that data bag in the data bags folder. And then push it to the Chef server and use it in our deployment later on. We'll do those things. But this knife configuration is ready. Next, we should be able to put that in git control. And I just gave you a shortcut to skip git just to cut your frustration, which is likely to happen. Because it is just long and pathetically boring if you think like that. So cut your frustration, at least. The preparatory steps are the most hard things here. The actual execution and accomplishing the desire is easy. One line, boom, it does it. But getting to that point, you have to really express your desire in a systematic fashion. And that is what we are really trying to accomplish, is we want to fill up our details in our environment, cookbooks, role, site cookbooks. That's what we want to populate with content that expresses our desire to accomplish something. What is that something? We want to run WordPress in SunCloud for our customer. And we want to do that in one command at the end that does it all. For that, we have to write down our desire. We will do that in these folders in our kitchen. Send the folders, upload them to the Chef server. And that's how we will express our desire. And then we go on vacation. So one question. Yes. So let's say if you want to do a failover and we have two servers in that, will this process move the content to both the servers at the same time? No, not this exercise. No, we have to go to the next logical step. This is just the idea of one box. This exercise, there are extensions to it. Just one box running all of these things, and off you go. The failover capabilities, we'll get to that. They're advanced capabilities. You want to be able to load balance dynamically failover, switchover, becoming, creating highly resilient services. In this exercise, we are limiting our scope to just one box. And then we will extend it to two boxes, and we will get to that. But right now, it's just one box. So git, skip. It is a bad idea to skip git, by the way, as I said. But it's OK. Skip. So skipping that. Then we get some community cookbooks. We're going to get some books. We're going to get the PHP book, Apache book, and MySQL book. So there is this MySQL book, the PHP book, and the Apache book. These three books, I really, really need. Everything else is a dependency. So I have, in this example, made sure that I get written down exact versions of everything I need, basically becoming exhaustive. So in this listing, we have is a collection of all the books that we need, and we are going to write that down in a file like Burke's file, except we are going to use a different file structure called Chef file this time. It looks kind of sort of similar. Burke's file, Chef file, same thing. Same idea, different tool. Librarian tool for this file, Burke's shelf for the other tool, for the other file, Burke's file. Basically, the same idea. You saw me discuss these two tools. I'm going to use Librarian right now. So this Librarian is what I will use, and that will go and save this file in a folder here. And the file will be called Chef file, as opposed to Burke's file. So slightly different name, slightly different tool, but the same outcome, same outcome. The outcome is you're going to get these books, and it will get us those books. It will go look at the Chef file, which is right here. And that's what I will run now, is there are these git commands. I want to skip them. So I'll skip them, and I'll just run a Librarian Chef and ask the Librarian, so please go get me these books. So that's what Librarian will do. When I run Librarian install, it will look at this Chef file and get me the books in this folder, like that. Please get the books. Off you go. So it will go and get the books. You can see that the books are coming down already in a TMP location. Librarian is grabbing those books and putting them in the cache like this. And that cache is building, but I'm not messing with it. I'm leaving it alone, because what I want to see is the books showing up here in the cookbooks folder. So the cache is actually building right now. It is going grabbing the books for me. It is doing that, as I can see in the TMP folder activity. But I will be patient. It will get those books for me, all of these guys that I need here. And they'll place those books in the cookbooks folder. It takes like two minutes. And so once that is done, we should be able to proceed to the next step. And the next step is basically a place to store custom cookbooks, which we already have. And there's the site cookbooks reference, which we already created. That site cookbooks folder already exists. This is a git command. And we can conveniently skip to cut down the work we have to do, so we skip. Next, I want to send my books to the Chef server. And that's what I will do once I have my books in place. They're coming down, not ready yet, but now they came. So the command finished, took it about two minutes. And then it looked at the Chef file, collected these books for me, and placed them in the cookbooks folder. So now I have them in my books. I think it is storing elsewhere, apparently. But it will succeed, because it did tell me, where did it store? Installing all these books, so the books should be available. And when they execute, they will come up in the right locations. Now we want to be able to send those books over to the Chef server. So we will go do exactly that. First of all, I want to clean up my Chef server. So what I want to do is delete all the books that I have in my Chef server. And so here we go kill the one book we have. It's called the starter book, and that was deleted. Now I want to send my books over to the Chef server, these books that I just downloaded. So I will be able to send them. OK, I made a mistake somewhere. So let's see where the books are. Bundle exec knife cookbook upload. I think the behavior has a little bit changed in the way library functions. So I do not see. I was expecting to see the books showing up here in the cookbooks folder, but they did not show up. So let's go examine what does Librarian do differently. So there is a question here that says, my guys like using Ansible more than Chef or Puppet. That is good to know. Most of their development, they are using Ansible. That is nice. There is a recent vulnerability. So if you, OK, let's see what the question is. Vulnerability. Most of their using Ansible, there is a local version. And the tower version, the tower is a commercial product. Why do I not see the whole chat here? OK, give me a second. I'm not able to see the whole chat for some reason. OK, so the comment from Kara is, most of their development using Ansible, there is the local version and the tower version. Tower version is the commercial product. Local version is open source product. There was a recent vulnerability for Ansible. So if you bring it into the enterprise of a company, you must patch management process. Yes, true. Absolutely. That has nothing to do with Ansible, per se, but just about any software. If you want to bring something into your company, you want to make sure that its vulnerabilities are removed. And then you use it. And everybody, every company I know, every software company will eventually run into some problem, like making a mistake and making your security issues pop up, like vulnerabilities pop up. You can see these things in a global database called CVE. This is maintained by common vulnerabilities and exposures. This is maintained by the US government, I think. And this database is where you should look at, which basically gives you the standard for information security and vulnerability names. Every vulnerability that you will discover, there is a method to systematically publish information about a vulnerability that you have found. And you will do it very privately, very secretly. You will tell the creators of that software that, hey, I seem to have found out a vulnerability in your software. You will disclose that systematically only to the company or the people that create that software. And this CVE database is where you will find almost all vulnerabilities that have been disclosed to the public. So for example, there was this vulnerability long while ago, I think, about a year or so ago. It's what's called Heartbleed. You may have heard of this thing called Heartbleed. It was a vulnerability discovered, and it has a nice little logo for it. And so the idea about this vulnerability is that it's defined in this number, the CVE number. So you can go to that database and find out what Heartbleed is, what the issue is, and then read more about. So you can search the CVE list and view entries or view by identifier and submit. And there you can find out the specific reference to the Heartbleed bug, which was a vulnerability in open source. So that's how you go and carefully examine vulnerabilities that are known. Once a vulnerability is known, there is usually a fix for that available. So that's something that I think is a proper procedure that I'm trying to point out, because that is a common question in corporations. How do you know whether something is vulnerable or not? It is really hard. If there is some product and this creator of the product, they will create this product. And people are using it. And so this product is useful, nice, and lots of people use it. And so this person using that product finds that this product has a vulnerability. So the proper way to disclose that vulnerability is to not post on Twitter. And don't do that. But instead, send a private message to the creator and politely say that, you know what, I seem to have found out a vulnerability in your product. And they will thank you for that, by the way. Really thank you. Sometimes companies will pay you big money and compensate you to help them find a vulnerability. Facebook does that, yeah. Sorry? Facebook does that, yeah. They pay people also. Yeah, yeah. People will gladly thank you, pay a ton of money to help you, because you help them find that vulnerability. And so you report that in a discrete fashion to the creator. The creator will very likely thank you and compensate you if they're a big company. If they're a small individual, a bunch of people developing open source, they'll just thank you. May not compensate you, but if it's a big product like Google product, Facebook, Amazon, all large companies, they will give you both lot of money. And so you do that secretly, just with the creator. Tell them that you have a vulnerability, and they will probably fix it and push the changes to the product. And at that time, they will go back here on the CVE database. Where is that CVE? Here. In that CVE database, they will publish with an ID number that our product has this vulnerability, and there is a patch for that, and that you can download and install. And most of the times, those patches are pushed out to the customers already before they know. This is what you see in Windows updates. Most of you have Windows, and you know Windows updates. And so if you go to see a Windows update, you will find that when you run Windows update, or let's go Windows. We have Windows running. So you go run Windows update, and check for updates. And so here you will see that update history, and you will see that this KVE. So for example, this is a knowledge-based article which will tell you about what that update is for Windows 10. So if you go read that KVE, for example, I'm going to copy it from here. And let's see if I can copy properly. Copy, and go do a search on that. And you will find that it contains a bunch of CVE occasionally. So the details about that particular update that came down for Windows will have a bunch of vulnerabilities addressed. Sometimes it is not vulnerability. Sometimes it is. And so if it is an update to Windows, like for example here, there will be security updates. And those are typically CVE updates. So here is a security update for Windows, for Office. And so you will look at that, and that will have a vulnerability that was addressed in Microsoft Office by that number. And let's go see that number, what it does. And you will find the security update here will actually address a vulnerability in Office. So a security vulnerability existed in Office 2016 that will allow arbitrary code to run when maliciously modified file is opened. This update resolves that vulnerability. If you go read the details, you will find the security bulletin. And in that bulletin, you will find a reference to the CVE. And where is CVE? And so here is that vulnerability. CVE 2016 0126, Microsoft Office was vulnerable. So back to our CVE database, you see that this CVE ID was resolved in this update, which was pushed out on February 5. And at that time, this CVE was also disclosed. So the world knows about this vulnerability from the CVE database. And at the same time, Microsoft pushes out a security update to address that vulnerability. So in your corporations, you probably have this vulnerability already, even though you think you do not. So prior to this date, for example, prior to February 5, I had that vulnerability right here in this machine. Microsoft fixed it with this update. You probably had the same vulnerability also if you're using Microsoft Office, even in your big companies with all the procedures that you follow, you will have that vulnerability. You are just living with it, and you do not know because you are blissfully unaware. But you have that problem. You may not know it. Somebody knew. Somebody figured out. And so they figured it out. They complained to the creator, which is Microsoft. Microsoft fixed that problem with this update called KB31150, whatever that number is. They pushed it out as a security update to Office through the Microsoft Update methods. And then they go here and talk about it. Hey, we had a bug. Hey, we fixed it. And we thank the person who found out all that good stuff. Now, this is what is a systematic patch management process. And that is what Kara is referring to. So if you look at Kara's chat, she's saying that you must use patch management process. And that is an example of how Microsoft manages patches, security updates. And this is important for you to keep track of. You have to really dedicate a team that is dedicated to understanding vulnerabilities in a piece of software that your company uses, and make sure that you systematically take those patches into your organization. An example of the same thing in open source will look something like this. So you have, say, Ansible. And so the Ansible product is on GitHub. And so you will go to GitHub. You will evaluate this product. You will look at the appropriate tag number that you want to use. And so you will be maybe using this version, for example. And this version was released on October 31st. So you're using 2200-1. And let's see in our machine here, what are we using? Ansible, I'm using 2200, so a slightly older version. I'm using 2200, that one. I think that's the one I'm using, so 2200. This is the one I'm using. Now, if they find something that is actually defective or vulnerable, they will go and patch it. These guys who create that product, these two, two, five, two creators, these are the people that create 2,522 people, these guys will collectively create, update, and maintain the product. They have, by the way, updated it to this version. There are some changes made. And the latest commit changes are these. So they made some changes. You can see that these changes are incorporated. And as a consequence, the release was modified from this version. Earlier, it was this version. Now, it is this version. The version number changed. In addition to that, certain other changes in the code happened. Now, any time a change happens, you have to take into account that you are carefully understanding what changed between this 2200 versus 2210. Carefully evaluate that, and then incorporate this latest tag, which is 2210, after you really understand as to what did they change, and then accept that. This change acceptance, bringing changes, bringing updates into your company, has to be done by you. Open source people will do it on GitHub, like, for example, here. They may not push those changes to you, like Microsoft does in this example here. They just push you a security update, and you receive that. Open source doesn't work that way, necessarily. You may have to go and modify the exact version of Ansible that you want to use in your company. You can, even today, use an old version of Ansible. Like, for example, you can go all the way down and use the version 160, if you like. No problem, it works. It is created in 2014. That also works, and it's OK to use that, provided you are happy with it, and that you know that there are no security vulnerabilities that actually impact you. And then you can keep using the old version, if you like. But if you know that there is something wrong with this version that actually hurts your company, then you want to go a little bit higher and find out where is that problem solved. So there are all these changes that are made with the specific version numbers available. So maybe version 170 has the fix for it. So you go take that and use that version instead. You don't have to go rush to the latest and greatest all the way up to this point. Don't have to. And that is what Kara is referring to, is a systematic process of patch management. So you incorporate changes that are appropriate for your company, for your project, and you understand the vulnerabilities that exist, and make sure that they don't actually impact you. Sometimes vulnerabilities are OK to live with, because they don't impact you at all, because you don't use that portion of the code. And so it's OK to live with that. It doesn't hurt. But you have to do a security analysis about what is actually impactful or not. If it is impacting you, you better patch it. And that is what Kara is basically suggesting, is to be careful in managing your changes. It's the entire change management process. So when you take new software from outside in your company, you evaluate carefully, and then make use of it, and have a systematic method of receiving updates to it. And you regulate what comes into your company. OK, CVE. Remember, this site is actually a very useful site. It is kind of hard to read. But I guess it's deliberately hard, honestly, because we don't want to scare people with vulnerabilities. It can be scary. And so Microsoft tries to write it in a language that doesn't sound scary. For example, here, it says security updates. And they hide that information underneath in a very succinct fashion. So if you go back here and look at the KB article, this knowledge base article, they will talk about these things in very subtle fashion. They will say something like, remote code execution. What does that mean? It means attacker from Russia is taking control of your computer. That's what it basically means. If you write it like that, it can be scary, right? But remote code execution exactly means that somebody from Russia is controlling your computer. And I'm just blaming Russians for no reason. I'm just saying. The reason I actually say that Russians is because I have a reason to say that. And even I get hacked occasionally, at least attempted hacks on Cloud Genius site. You will see some Russians hacking Cloud Genius all day long. I see that all the time. And I'll give you just a quick example before I digress too much. So here is security logs, and you will probably see some Russian trying to log in as admin. So here we have this guy, invalid login attempt at February 11th, 7.57 in the morning, log in as admin. Who is this guy? Click. This guy is in Surgut, Russia. You see that attempt to hack me is happening all day long. And so what I will do now is take this IP address and blacklist, pretty much like that. I will do exactly that I just said, which is to go back to my configuration and blacklist that IP address so that nobody can log in from that site. So here we go. All these Russians keep hacking me or attempting to hack. I added this guy and saved. So nobody from that IP address can now visit CloudGenius site, period. They will not even be able to open. Using bots, then this becomes difficult, right? I know. And so I'm just illustrating this point just to tell you how to do it systematically. So I have a method to deal with bots also. But I'm digressing. I just showed you an example of how to do this mechanically by hand. I do that by the way systematically. So when I see a bot trying to log in, I will automatically reject that. But I'm just showing you an example of how the bot can be addressed. You can automate that also. But I just showed you an example just to blame Russians. And that was a Russian site. At least one more question. Whose responsibility is to update the conflict management tools? Who takes care of that? It will be the day one. You. You are responsible, right? It's scary or it's more of a responsibility, right? It is. It is a collective responsibility. The open source community helps you. But at the end of the day, it is your problem. If something goes wrong, you are screwed, right? So it's your responsibility. The bot stops with you. Bottom line. Something goes wrong, you are screwed, right? So you are responsible. You have to understand and fix it. If you don't do it, it is your responsibility. Otherwise, you will fail. And so who's responsible? You, honestly. OK, enough security. Let's move. Let's stay focused on this. So what I was running into this problem is that this library and tool seems to have not deposited my books in the right place. In the cookbooks folder, I don't see them. And I am curious as to what changed. So I need to send my books over to the Chef server. So I need to do that. So I'll adjust my screen a little bit. And find out where that cookbook went. These cookbooks went. So bundle library and Chef install. Where did this go? So these books must be there somewhere. So we'll go to the home location and find out, try to locate the books, where they are. Or another way to look at the same thing is to ask the GitHub community, where did librarians start putting them? So librarian chef cookbook location. OK, it stores in this location, apparently, somewhere in.librarian. So let's go to that librarian location. No, no, it is not that location, for example. I am not able to find it. So it's somewhere else. And that's a change that I think I'm running into, which means I need to modify and not use Librarian, but stick to Berkshelf. And I will do that. What I will do is change my Chef file into a Berks file and use Berkshelf instead. And this is a deviation from what we have written down. What I'm going to do, since Librarian Chef seems to have placed the books that I don't know where it kept and I have no quick way to find out, what I am going to do is use this Chef file, rename it as Berks file. And now I have this Chef file.lock, which I can get rid of. Now I have the Berks file. And I will use the Berkshelf gem, Berks install, to install my books. That's what I will do, just like the last example. So this example that I just have, I basically made a change in the writing written steps here in the walkthrough. I'll go back to the previous example where we use our Berkshelf tool to get us the cookbooks we wanted. In the previous step, you probably know this from. Nilesh, can you do a grep on the cookbooks extension, something like that, using grep? There is no extension to books. So you cannot go look like that. And so I will identify what may be the reason for this issue that I'm running into. And I'll come back to you later. But I don't want to waste time. And I will proceed forward. So I am basically looking at a good Berks file example. And that's what I want to be able to do. So where is the other? Last example had us working under downloads. Huh? Where? If you go to file manager and look at downloads, and then there was a repo underneath. No, downloads. Oh, OK. Yeah. Oh, there you are. There is a book. Yeah, I was going to tell you. Because it says something about the temp directory there, yeah. The books are here. Yeah. So yeah, I think we found the books. So let's go stick to what we were doing. So back to here. And books. And this is the chef file that we have renamed it. So I'm going to delete the temp folder completely again, like that. And this Berks file that I renamed, I'll rename it back to how it was. Chef file. And then I deleted the tmp. The chef file looks just like what we have in the example. And I will run the command to get the books loaded. And this will bring down the books in the tmp folder. It should actually place in the cookbooks folder, I'm expecting. And there it comes. I think there was something wrong, some hiccup. And I want to make sure that this hiccup is clearly understood. So the books came actually in the right location. I can see them. I want to basically do this one more time to make sure that we are in good shape. So I'll break this, breaking it. And removing the tmp folder. Removing the cookbook folder also. That is gone. Now cookbooks are gone. Tmp is gone. Chef file is in place. I want to create a folder called cookbooks. Now that folder is there, empty. My tmp is erased. And now I will run the command again. This should place the books in the right spot, in the cookbooks folder, correctly. But it did not, for some reason, when I first tried, very first time. And so the second time it seems to have done something, which is nice. But I want to eradicate any confusion. So I killed everything else that we had. Tmp was gone, and cookbooks was gone, and we created a fresh cookbooks folder. And then we are running this library and chef install again. And I'm expecting this time it will first collect it in the tmp folder, and then copy them over here. I'm expecting that to happen in two minutes. We'll wait for that. The key is patience. And I don't have that. I don't have that. But that's what I'm trying to accomplish, is to just be quiet and let it finish. While it does, what I want to do is to articulate this idea, is what we are really trying to do is on our workstation, we sit here, and the chef server we have here. And we want to send our books to this location. That's the goal. But we want to send cookbooks to that location. But why can't we have a method where we can get from the supermarket and ask chef server to get the books directly from here? Why do we have to upload? That's a question some people ask. Why do I have to upload the books that are already there in the supermarket? Why can't chef server get it directly? Why do I have to upload? The simple answer to that is, this is your desire. You want to change something in the books that you send. And that is the only way you can change, and that you should change if you want to change something. Because this is not somebody else's desire. It is your desire. So you need to be worried about sending exactly what you want the desire to be. And that is why it is important that you send your desire to the chef server. So this command seems to have completed. Let's go exit. Let's go exit from here also and here. And then open fresh terminal, go to Chef repo, and find out what our cookbooks contain. And we have the books now in the right plot, which is nice. Let's go open Atom editor and see it visually. So here comes Atom. And we will see them. The books are in the right location in the cookbooks folder already. And these are exactly as specified by the chef file. In the first attempt, I did not see these books in the right spot here. And I was a little bit worried. And that is a sign of lack of patience. So having done that part, I want to make sure that my books are sent to the chef server. So we'll do that. Next step is to create a place for our site cookbooks, which we have done. This is a git step, so we skip. And then we remove any old cookbooks we might have in our chef server, so it is all that. We have erased it already one time. So I don't have to erase it again. And now I want to send my books over to the chef server. So I will go do like that and send my books over to. OK, take my book, please. So here it goes. So it's going to the chef server right now. And you can see that my chef server currently does not show any books because they don't have any. But soon, they will have my books. So here I log in. And as I log in, by the way, chef server is slow because it is free. We are using the free version. So the books do not have anything there yet. You see that there is a node here from the last time. I want to kill that node. This is the last node that we created in the last example. I want to delete that. And the node is deleted. Let's go policy in cookbooks. And these three books show up. And these are the ones that are being added. So it's sending right now. The sending also takes two minutes. It's a large collection. The books are going there. And then we want to fill it up with roles, data bags, environments. And then we are basically done with expressing our desire. Once we express our desire, write that down in a kitchen and send it over to the chef server, we are then ready to create our infrastructure and load our configuration just like we designed in our example. So we have sent the books. Next, what we want to be able to do is create environments. The idea of environment you probably heard me say before is that you define that I have a development environment, that I have a stage environment, that I have a production environment. And I will do my messing around here. And I will maybe show my boss, show my boss. This is what I got in the staging environment. And then show to my customer what I have in the production environment. That's what I really do. This is where I create mess. This is where I clean up my mess and show it to the boss. Boss says, OK. And then I say, go. Send it to the customer. That's the flow. That's the broad way of three different environments that I want to play with. So I'll basically have a replica of whatever I have here. I will create it here for the boss to see and inspect and approve and create it here for me to play and mess around with. So three different environments is what I really want to construct. These are logical way of thinking about. I want to be able to create mess, a lot of mess here. And I'll do that. Here I want to clean up in the staging and make the boss happy. And if the boss is happy, then we can go to the customer. So we can make the customer happy and then make money. That's the idea. So the three environments are just examples. These names, the dev name, the stage name, broad name, these are just names. You can call them cats, dogs, and mice. Doesn't matter. The only name that is reserved is this name. Default, underscore default to be specific. That is a reserved name. And that's given to you already. You can see that here in the environments. There is a default environment already given. The production environment, I delete that. And the dev environment, I delete that. And I have to read by the way this is a bug in Chef server. I have to refresh the browser. And then I can delete the dev environment. And that sucks. But I have complained about it to the Chef guys and they'll not listen. But you can delete that through the command line. It's much easier. Bundle exec knife environment, delete, and stage. You can delete the staging environment just like that. And I deleted that. Now do I have my environments in order? Can I list them? I'm going to list them. And I see I have only one environment called the default environment, actually underscore default. So I can refresh that. And you cannot delete it. It's a default environment. It's given to you to begin with. Now you can create cats, dogs, mice, whatever you like, like stage, dev, product, prod. They're just names. They're collectively a way of thinking about what the goal is to be able to develop something, to create mess, to test, to do whatever you like, to be able to show your boss in a staging environment or customer in a production environment. So there are three ways to classify, basically. And so you will create those classifications in form of environments that are basically Ruby files with this line, two lines. So you go here, create a file, save this content, save it in the name, in the folder called environments, environments folder. And you will call it dev.rb. That's how you create an environment. That's it. So very simple. I'm going to create a Ruby reference that I'm going to call this environment dev.rb. And one more here. This is the staging environment. So we'll call it new file, save in the environment folder. In this folder, I will call it my stage environment, stage.rb, and then close, close. And then the third one, production environment. So I'll save the content, click in the environment folder. And in that folder, I will call it my production environment. So prod.rb, save. And I have these three roles, dev, prod, stage, with three different files in there. And that basically looks like these two lines. So the prod file will be something like this file will have this unique name, prod, file name has to be the same, matching. In the description, you can call it whatever you like. I don't care. It's just human English, people English. It's not Ruby. So you can close that. Don't have to change it. The description is irrelevant, so don't save. And now I want to send these three distinctly different roles over to the Chef server. So I will do exactly that. So I will just go here and send my three roles, sorry, three environments to the Chef server like this. Bundle exec knife environment from file boom, boom, boom goes. It goes there, right there. And you refresh the screen, and you will see those three new environments pop up. Dev stage prod, simple, not that complex. It expressed my desire to have three different environments to play with. And I told that desire to Chef server, so it knows. Next unit, this idea of a role that I want our machines to play. So the idea is to assign a purpose in life, a purpose. As in, I want you to grow up to become whatever you want to become, like a database server, a web server, or this server, that server. What you want to do, you have a desire. You want to assign that purpose in life to a machine that when you begin just enough OS, I want you to grow up to become a web server. That's the role that you will take on. So in a web role, what you will have is basically run Apache. And so in that role, I will have to specify that you will run Apache and PHP so that you can correctly function like a web server. Another example, this machine, I want just enough operating system, and I want you to grow up to become a database server. And by the way, MySQL database server. And so I would like you to run MySQL and PHP, these two things. And by the way, Apache is not needed in this box, in this J-E-O-S box. I want it to be just the database server, so I need MySQL and PHP. And of course, this idea of LAMP comes into play, Linux Apache MySQL PHP. But here, what we are really doing is designing two different ways of the same concept, Linux, Apache, and PHP, and Linux, PHP, and MySQL, two boxes. This is our web server. This is our database server. We needed four things. We got split like this, so web server separate from database server. The two boxes we'll have eventually. Right now, it looks like this. So we are creating two roles, the web role, the database role. These roles will contain something like here, like I'll describe. But before that, there is one more thing, which is everybody needs to get this common element, Linux, plus something else, like basic necessities, for example, Git. And so I need to install Git on all these boxes. And that is a separate role I want to create. I'll call it the base role. It is common to every machine I will have ever in my environment, in my cloud, in all my clouds, in all environments. I need to have every box to have Git. That is the base role. And that is what I'm trying to define here in this example. I'm creating a role for a machine. The role happens to be the base role. So I'll create a new file, clip, paste, save in the roles folder. In the roles folder, I will save it as the base.rb, the base role, base.rb, save. And in that roles folder, I now have that base role, which looks like this. It has a name. It has a description. It is the base role applied to all the nodes you can have. And they will contain apt to update the apt cache. Every machine needs to be fresh and get the latest Ubuntu updates, like Windows updates, like Macintosh updates, like apt cache Ubuntu updates. Everybody needs to have Git. That Git repository will be useful. In our all boxes need to have Git applications, so that is installed through a Git recipe. Everybody needs to have build essentials. And these are essential components needed for us to build something. These are the essentials needed for building a product. So that is the build essential package you need to install. You need to also have super user privileges, sudo. You need to have an editor that I personally like, the vi editor. And users, colon, colon, sysadmins. You want to assign a chosen selected number of people to have privileges to access the machines out there in the cloud. Not that they will. You need to have that ability to have certain people in your company to get access as system administrators on those boxes you will have in the cloud. And so that cookbook called user's cookbook with sysadmins privileges will allow you to do that. And you want to get that as a run list for all the boxes that become your base role. This is like given to every box, base role. And then you're providing specific authorizations as override. What you're really saying is I would like to have a user called Ubuntu and a user called Vagrant and a user called whatever else I like to be able to log in and escalate privileges in super user mode without having to type a password. Passwordless sudo override. These guys with this name and this name allow them to use passwordless sudo and just let them escalate privileges if they need to. And that is what this override attribute defines. That is given to every box in your domain, in your cloud, in every environment. And this is the foundation, the base role. Next, we'll create two more roles, one for database and one for web server. Next one is the web server role here. In that web server role, I will have a file saved in that location called the roles folder. And in there, I will give it a name. The name is web server RB. And that file pops up right here. It looks like this with the name matching the RB extension. It has the description web server role. In that role, I will say, you know what, you better get the base role to begin with. And then add PHP, add Apache. And you're done. There are a couple more things. Like you add a PHP module MySQL, add a mod PHP rewrite, and mod PHP 5. These are dependencies as required by WordPress. You remember WordPress says, get me this, mod rewrite. So we've got that. And so these are the things that I need to have the web server do, begin with the base role itself, and then add PHP and Apache. And by the way, do this thing on all the boxes that will become my web servers. That's the role definition for my web boxes. Run this for all environments, except if you are doing development work in the development environment. I would like you to enable the debugging capabilities, PHP xdebug. This module will help you debug PHP code. If you're a developer, you will uncomment this and hide the line number 19. Instead, use line number 18 in your development environment. And that will allow you to add extra capabilities in your environment, automatically get you debugging capabilities. Because you are creating mess, creating something, creating, building something new. You're doing that in your dev environment. In production and in default, you are basically running all of your things, just like defined here. Begins with the base role, add PHP, add Apache. Remember, we are not adding MySQL here. We will do that in another role. This role will be the database master role. And that is a separate file. Looks like this, save it in the roles folder by the name db underscore master. That's the name I have chosen. And the extension is.rb. You will see that the name here matches the extension, db master. The description is just English language. In there, the environments are get your base role in order, get the base role first, and then add one more thing. And that thing is called something weird. What is that thing? This weird item is called your SQL, as opposed to MySQL. What does that mean? Is it a joke? No, it is not. It is something that doesn't exist quite yet. But I will create it, because this is going to be your variation to the MySQL cookbook. So you will use the MySQL cookbook, but you want to vary it a little bit, override it just a little bit, and make it your SQL, as opposed to what the community has provided, called the MySQL cookbook. So MySQL is there, but it is the way that they do. But I want you to do it your way. And you want to use your password. And you want to use your detail secret. And you will put that in your data bag. And you will encrypt that data bag. And you will send that data back to the Chef server so that when this MySQL cookbook runs, actually, I should say, when your SQL cookbook runs, it will use your secret from your Chef server and grab the data bag, encrypt and decrypt it, apply that password to your SQL installation. And that is going to be a different cookbook that we are referring to right now in line number six here. It doesn't exist. There is no such thing called your SQL cookbook right in our site cookbooks folder. That's where we were supposed to keep our cookbooks. The site cookbooks, it doesn't contain anything yet. We have a cookbook called MySQL, which is right here, and all that good stuff. But that's not what we are referring to. We are going to refer to this book, your SQL. And we will get to that. But for right now, let's create the role. And we'll send these roles over to the Chef server. So let's begin. We'll find out what role do we have. And apparently, there is a role called starter. So I can delete that role, say bundle exec knife role, delete, starter. So it gets rid of that. And then I will list my roles again. And now I don't have any roles. So my role list will be empty. And that came back empty. So now I want to send my roles. I have three roles here. No, my three roles are base, DB master, web server. These three roles I want to send. I want to send it to my Chef server so that it knows that I will have these three different types of roles on my machines. Base role, DB master role, web server role. And I would send these roles like this. Copy that. Paste it here. These three roles go up to the Chef server here. Right now, you see the roles contains nothing. But now it is getting created. So the three roles now are available. I will refresh. And you will see three roles here. The base role, the web server role, and the DB master role show up. You will also see something here which is expected, is that there is this red flag. It says, you know, cookbook not found, the YourSQL cookbook that we have in our DB master, this reference to line number six, it complains, cookbook not found. I don't know what you're talking about. Where is the YourSQL cookbook? It doesn't exist. Yes, it doesn't. I know. This listing of cookbooks doesn't have the YourSQL cookbook because we never created it. There is a MySQL cookbook somewhere here. It should be here. But it is not YourSQL. It is MySQL. So that's the reason why you have a complaint there in the roles for this item. This red flag shows cookbook not found, expected, because it doesn't exist. But we'll create it and send. But before we do that specific YourSQL cookbook, we need to also worry about a sysadmin user. We need to be able to have a method in which our users, those chosen people in our company that will be able to connect to any box you like across the board in any environment, in any cloud. And on top, you want them to be able to log in without a password and also escalate privileges without a password, which means we need to have a key pair, SSH IDRSA key pair, that will be injected in all the machines out there. And for that, we need to have a systematic method of providing our public key. And that you can store in a JSON file in a data bag. And it's a public key, so it doesn't have to be encrypted. It is public. So you will create that data bag right now. And that's what we are doing in this step. We are creating a sysadmin user and using our public key in that. And so this is the public key that you know already. We'll see it like here. You see that, the public key that you know. And we will take this key, put that in a bag in our data bags folder, and send it to the Chef server. So Chef server knows, OK, use this public key. It will do that. For which, you have to follow these steps. The steps are written down right there. We'll just take them and follow. So it did something. It opened up an editor for us. This is the editor. This editor opens up right there. And it is hiding here, so I'll bring it up front. And this is your editor that's open with an empty item. It says user.json. And that, we had to fill it up with this content, like this. And this is the most tricky part, by the way, in the exercise. The most tricky is right here, right now. So watch it. Paced. The tricky part comes in the fact that you have to really paste your public key in this segment. That entire thing, paste your public key here. That's where you have to really paste your public key. And you can get your public key from here. It is available to you like that. So you'll grab from here all the way up to this point. Don't get the user at cloud genius thing. Don't get that part. Be very, very meticulous and grab from here. All the way up to SSH RSA. That is what you need to grab. Begin from SSH, all the way to the end. Don't get the space. Don't get the user at copy. And this is what you need to go bring it here to this editor and replace this segment. Be very careful. As you paste, you want to remember that after the paste, there is a closing quote and a comma. You want to keep that, not get rid of it. So now I'm going to paste. Basically, delete this and paste my public key right in that spot. Paced. You will notice that at the end, there is a quote, close, and a comma. You want to keep that safe. And if you make a mistake, you will notice that this editor is smart enough to detect that mistake and point out in red color. For example, this. Make a mistake. Remove the mistake. Make a mistake. Remove the mistake. It's smart enough to understand the mistake in JSON, and it will tell you that. Now you see that the error is not there. You can do that. Now you save. When you don't see a red flag, you save, close. Now you have created a data bag item. And that, I think, is the most tricky part in copying and pasting, and the logistics of that is the hardest. Now you have a data bag item called users, and an item called user JSON. It has the key that contains your public key all the way to the end, the other end. You have users defined called user. You have a group defined called sysadmin, dba, devops, the shell assigned, and the user ID assigned, and all that. These things are a data bag item, and you want to send that item over. And this file is a backup file. You want to get rid of that file. And so I'm getting rid of that file, move to trash. And this user JSON is the actual file that you actually send to the machine out there. So in my data bags, you will see that I might have a data bag item there already. I will delete that. And then I will delete the other item also. There are two items there from the previous step. I'm cleaning up, and I just cleaned up my data bags in the Chef server back here. I want to now check the list of my items in the Chef server. So here we go. What do we got? I got nothing right now. And so the data bag list is empty. I want to now send my bag called users with one item, user.json, that item that you see there here, this item. I'm going to send that over. So before I send, I will create a bag called users like this. And in that bag, oh, sorry, no, not like this, copy. And create a bag called users. And in that bag, I will send an item called user.json. That goes to the Chef server just like that. And so the Chef server now has this bag called users with an item called user with my public key right there and a group membership to sysadmin, DBA, DevOps, all that. And basically, a reflection of what you have here is what you see here in the Chef server. That is just one bag, one item. Next, we'll create encrypted data bag to store our database passwords. And that encryption requires creation of an encryption key. We don't have a key here in our Chef folder, dot Chef folder. So we'll create an encryption secret just like that. You've done it before. So I'll just go fast, like this. So you have an encryption secret created. It looks like this. That's our encryption key. Now, having created this key, I want to go to the Knife configuration file and uncomment the very last line. Uncomment this line after you create an encryption secret. So now that I have the secret, I can uncomment and save. This will allow me to use the encrypted data bag secret that I just created back here. I want to now use this, the thing that I just created, the encryption key, to create an encrypted data bag remotely. And this is also kind of tricky to understand. You will see that this file was created locally right here using an editor. And we created that editor, and we created the file, and copied and pasted, and all that good stuff. But this time, we are creating an encrypted data bag with an encrypted data bag item to store our passwords. And we will use the same editor like the last time, but that editor will save that file in the Chef server directly. It is a remote editing tool. It doesn't save it locally here. It will go straight modify this location as you execute this command. And this is going to first step create a bag, an encrypted bag called secrets with an item called MySQL. So the idea here is to naive data bag create, use the secret, create a bag called line number 8, that's the bag name. Line number 11 is the item name. This is the bag name, secrets. That's where I will store my secrets. And this is the item called MySQL. This is the secret file I will use. And please create a bag like that. And so this command will execute an editor that will edit the file away from us. It is not editing a file here on this machine, but opening the editor in a remote computer, which is the Chef server. Off we go. And so editor opens up. This comes up with an ID called MySQL already. And I want to modify this JSON to include my passwords. And so that will make it look like this. So I will modify this file like this. And I'll store my development root password 123, production root password 123, like that. I'm storing this detail in this JSON and saving it and closing it. And you will see that it created data bag item called MySQL. Where does it create? It does not create here. You see that the data bag folder does not have that secrets item quite here, but it is created here in the Chef server. You will see that it has an item called MySQL in the bag called secrets. And you can see that the item is right there. It has the development and production dev and prod elements that we created in our JSON, you remember. Except you just told your secret password to the Chef company. And they will now be able to read that detail from you. And they will know your database password. Is that the idea? No. Because when you expand it, it is encrypted. So they will have no idea what your actual password is because the data itself is encrypted. You can see it. And you can actually, if you make a mistake in this process, by the way, this red line here actually is a way to delete your data bag if you like. Now, it is commented out, so you don't accidentally execute it. But it's there for you if you make a mistake for some reason. Something goes wrong. You want to delete your bag and create it again. That's what you would like to do. So now that I have this bag created remotely and the bag is encrypted, I don't have a local copy of it. So I would like to get one. And that's what I will do next. I will actually create a folder here locally in that location in the data bags folder. I'll create a folder for me to store my local copy. So I create a folder called secrets. It is still empty, though. So I will now like to bring my actual JSON from the Chef server. So I can bring it down, pretty much like ask it to show me my secret. And so it will use the encryption key and show you your secret. And so here it is. And the response that we came back with was that development password for root is 123. Production password for root is 123. And the identifier is my SQL. But this structure is not JSON-like. I would like this to be written in proper JSON so I can store it in a file that I can make use of. So I have to export this detail in the JSON format with a dash fj option. I will now see the output in JSON. So now I see JSON right there. This is JSON. And I can now redirect the output to the bag itself in an item called MySQL JSON so that I will actually create this structure in a file that I would like to save in the appropriate local location, which is this folder. I would like to save it in that folder. So I'll just run it. It will create that file right there. It will be decrypted with the provided secret. And you see the outcome. That looks like this. So you see it like this. Chef server sees it like this. It is encrypted for them, visible for you. Question, Ilesh, where is the decryption happening when you're getting it back from the Chef server? Local. Local here. Decryption happens here. What command is that which does that? It is implied in this line. Thanks. So it is locally decrypting with the provided secret. That's line in the knife configuration at the bottom. Now that we have that file available, we can see it. We can put that in a Git repository or see the secret and all that good stuff. But let's proceed. You want to make a change to the secret, you can do that. You can basically run the same command, pretty much like what the create command was before. This was the create command. So you go modify it. And instead of the word create, you say edit. And it will open the editor again. It will go remotely examine the file that you have in Chef server. And here you get the opportunity to change your database secrets. And you save. You can do that if you like. We don't intend to, so I'm not saving. When you don't save, it does nothing. You can examine it did not change anything by running the show command one more time. So it will look up the data bag remotely, decrypt it, and examine that the password for root in production is still 1, 2, 3, did not change. Root 1, 2, 3, did not change. Still the same. Now we are going to create a cookbook, our own cookbook. And we are going to create a book in the cookbooks folder here, but not really. I want to create it here instead. This is where I create my own creations. I will create and separate them from the community creations. These are the community creations that are there already. I don't want to mess with them. I will create my creation separately in a separate folder here, site cookbooks. They're my cookbooks. So I'll create that book with very simple way of doing that is actually just one command to create a book. I understand some of you have to go, and it's Saturday, and it's already 11, 9. So maybe I should pause. Maybe I should pause and not let you lose. So there is a dinner at Monday, 6 o'clock. Yes, we are keeping 6 o'clock, Raj. You know you wanted to change a little bit, but nobody else responded. So it's sticking the same time, 6 o'clock on Monday, and I know some of you have to go. And so this 13th of February, Cloud Genius Dinner, I have sent all of you a request. Two of you have declined. I don't think those guys are here right now for some reason. But two of you guys have declined, but others are going to be there, which is nice to know. So I would like you guys to be there, and I look forward to seeing you Monday at that time. You have my phone number. If you need something, you can always call me. I will repeat my phone number in Slack chat. It should be at the bottom of the website, by the way. And so if you need something, call me. Let us meet each other Monday at 6 o'clock in the place that is defined in your calendar. Your computer's calendar should have it. And I look forward to seeing you at that time. I would like to actually pause this discussion in the flow of sequence, and we will continue the next time we'll do this, finish this exercise. It is a little bit long exercise, but it is comprehensive. It actually completes a goal, which is your desire to implement something. It will do the end-to-end game. And you will see that if you do this one exercise, you will actually stand to benefit a good depth of understanding about what this specific tool does. And we'll go play with other tools also. With that, I will pause the recording and open for discussion and questions if you might have. And I'll see you guys Monday, by the way. So if you have to go, you're OK to drop off. Yeah, see you Monday.