Hey guys, I'm recording this session so that you know that we are recording. We have a red dot blinking to indicate that it is being recorded. That recording will eventually appear. I think by tonight or something like that. It will appear in this section that you probably already know is the section that I have been accumulating the recording from this particular group. I am putting them in this segment, which is technically not the right description because I am going beyond cloud technologies and covering DevOps and architecture and other things. But I'm putting them here temporarily. I'll relocate them and arrange them in a much better way. I'm working on it. You'll probably see some changes here like the green markers are showing up. That's a new change I introduced. I don't know if you noticed that or not. But some changes I'm making into the site, into the content, relaying out of the content and rewriting portions of it. You probably will see that I'm changing the content on the fly as we run through the program. You will see that happen more as I will spend some more time in rewriting some of the old stuff and adding new stuff as I build new exercises. That is what I'm spending most of my time on is to create new set of exercises. The last time, if you remember and recall, we were doing an exercise on using Docker containers and that exercise was, I think, where was that? Written somewhere here in this one. That was the segment we were doing exercise, I think, somewhere along here. This was the one that we were doing, beyond that, next one, after that, this one. That was the Docker files for the Git repository that we used and that is this repository. We have it here and I have cloned it already locally available to me in that folder. That folder I can open up in Atom and that's what we were working on the last time. It has a bunch of series of things that we have been building along all together to get to a point where we will like to now run this into a cloud. We have run this locally. I want to run this whole setup in the context of a cloud computer. That's what my plan would be. This machine has Docker already. Come on, type properly. It has Docker already, as you can see. It shows you the Docker containers that were there the last time we were running something and I can always clean them up by saying, I need to look at my keyboard and position it correctly. Docker rm-f will clean out all the running containers or dead containers, whatever we have. There we go. Now we have cleaned up and we have nothing running. We'll also examine our etchost file, which I think we modified a little bit last time. That entry that I need to remove, these entries I think I already removed. Let me remove that last one entry also so that we have a clean setup. You remember that we were modifying this particular file to experiment with a scenario of running cnn.com, foxnews.com, this and that on our local machine. You remember and recall that. We were able to do that because we ran a example, Docker compose example containing nginx-proxy-c1 and we labeled this one as cnn.com and we had c2 and we labeled this one as newyorktimes.com and we also modified our host configuration file, this particular file. Now we don't have that modified anymore because I have it back to how it was to begin with. Now that exercise will not work because we modified the host file. That's why we were able to see cnn.com showing up WordPress. This New York Times showing up that different WordPress and this foxnews was showing us Joomla. That was the modification I did just to illustrate a point, but this time what I want to do is take the same exact exercise and run it in the context of a real machine out in the cloud. We ran these exercises right here locally in our workstation, which is just to understand what things are. What I would like to now do is actually grab a machine out in some cloud, for example, this one. You can choose any cloud. You can actually name a cloud of your choice right now if you like. If you have a choice of cloud, just name it. Otherwise, I'll go to the cloud that I like. I like it because it is quick. There's no other reason. It is super quick to create a droplet. That's why I go to that site again and again, although it is not the most comprehensive site that you would expect to find, but it's a good one. The reason I like it is good for developers. It may not be the best for production, but it is improving constantly. You can see that it now has Kubernetes service. It has databases available. That is a new feature set. These two feature sets are new. If you don't have access to it right now, ask for it and they might give it to you. These guys are enabling databases so you can have a PostgreSQL database as of right now, and eventually MySQL is coming soon. If you need those databases, right now MySQL, if you need that, it's not available, but PostgreSQL is, and that's the whole idea, is that they will evolve. You may want to use this if you like, but again, your choice. Right now, our focus is to get a machine ready. We're here to create a droplet as quickly as that. I want to cross-check that my IDRSA key pair is correct, because that is something that is important to cross-check. I will do that. I'll grab this key pair and make sure that I provide it to them, which is something that I may have or may not have. I don't remember. That's why I'm just cross-checking myself. Go to the security section and adding a key pair and adding this key, and it might exist. Pretty sure that it exists. It's already there. It says SSH key is already on your account, which means I don't need to worry about it. I just cross-check that. Having done that, I just go to droplet, create a droplet and create a machine that is a little bit more RAM than just this $5 droplet. I'll get a little bit more RAM, like maybe 2GB or maybe 3GB or something like that, or maybe $20 4GB droplet. That's a good size. I will select drop-down 1604, like that, 64-bit, this one. That gives me 160412. The thing that you will know is that this machine that we have, it doesn't come with Docker. Right now, in our machine here, we have Docker because I set it up for you. This machine that you are going to get, this, is not going to give you Docker. What's the solution? Well, we have to find out various solutions to get Docker to work on any machine that we obtain. I will have a sophisticated Ansible-based solution available for you in a subsequent exercise. Soon, we'll cover Ansible also, and so we'll go through that exercise. It is available in the example that we have. That will give us an idea. I think the Ansible example, I think, are written down somewhere here. We have, and that is the accessor I'm actually referring to is this one. That Git repository will take you through that exercise. We'll run that exercise, but before that, we have to understand Ansible. We'll get to that point, but right now, we need to get this machine that we have up and running with Docker. It doesn't come with Docker at all. We have to have Docker somehow installed, so we'll do that. Before we run our exercise, excuse me, before we run this exercise, the Docker files exercise that we did the other day on our laptop or desktop, we'll do the same exact exercise, but in the context of cloud with actual, real examples of making sure that we work with SSL and all that good stuff, SSL as in HTTPS certificates, which is what we have here, as you know, the certificate that we have available from GitHub. This one has a certificate available from Let's Encrypt, and that authorities, these guys give us certificates. The certificate generation is automated also, so you'll see those examples coming up as we work this exercise on the right side in the context of a cloud machine like this one. That machine needs to, first of all, get prepared with Docker, so we'll do that first. Then run this exercise and add SSL TLS capabilities, meaning add the certificate so that it works with HTTPS. We'll incorporate that feature set just in a bit as we get to that point. First, let's get a machine and then connect to it and make sure that it has Docker. That's my plan right now. I am going to select San Francisco, which is kind of close to us, most of us, maybe not. Some of us, I think, are closer to New York, and some are closer to San Francisco, but I'm just going with San Francisco as such. I'm also selecting the key pair that I have in mind, which is this one, this key pair. I have selected that right there. Then I will give this machine a name. I'll call this my Docker box, call it whatever you like, it doesn't matter, and then create a box. That's how it gets created. Then I will soon get an IP address, and that IP address is right there. I copy it, and then I connect to that Docker box simply. Although I call it Docker box, it doesn't have Docker, but I want to have Docker there. That's why I'm calling it Docker box. It doesn't have Docker yet. Having said, let's get the machine ready. It's getting ready, and now it is ready. I want to connect to it, like this, oops, no, like this. I paste the IP address and connect, so I get connection refused. Now I connect, and I'm connected. Now we want to have Docker running here, but it doesn't have Docker, so we need to install. The best way to install Docker is to just read Docker documentation, Docker install on Ubuntu, and so there it is. That's the best way to install Docker. It's fairly elaborate, and so we will get to this right way of setting up Docker later. Right now I will follow a quick shortcut, and that shortcut is right here, and just run that script. That's a shortcut Docker. It's for testing. The way to run this script is grab that line first on the remote machine in DigitalOcean, and then we will invoke that curl command, which will bring down a script. That script will just set up Docker for us very, very quickly, and that is how you invoke the script like that. We go to get.docker.com. The website is not very helpful. It's not super friendly, but that's a shortcut. It is not supposed to be used for a professional installation. Installation steps professionally done the correct way are here, but I am just taking a shortcut right now. We will go through this also and do it actually automated fashion using Ansible. That's a subsequent exercise. I'm just taking a shortcut route to quickly set up Docker on this machine using a script that's already written for quick and dirty installations just to get Docker running quickly, and I think I have it running here. So apparently it is already functional, so I need to go activate it on engine. So simply activate your Docker engine. Let me read this. So it finished the installation. It is telling us if you'd like to use Docker as a non-root user. We are not interested in that PC yet. Docker Engine Enterprise, I think we are done. So yeah, the setup is complete. So I'm going to exit from here and then connect to that machine one more time, and then check do I have Docker? I do. Sweet. That's a quick and dirty way, by the way. It is not recommended for professional enterprise-grade deployment. So we'll go through other methods. The actual formal method of installing is this method on this page, the documentation page. That's what should be followed. So it becomes more maintainable. This method that I used is not maintainable, but we'll get to this later in another subsequent exercise. So I'm skipping that one right now. I have this machine called MyDockerBox. Now it actually runs Docker. Sweet. Now on that machine, I want to bring this Git repository. This Git repository, I can clone it directly from there, and I say, hey, can you Git clone? And so it should clone for me, and now I have it. The thing is called Docker files. So that folder is available to me, that one. And what I want to do now here is bring up the stack. Before I bring up the stack, I also need to have Docker Compose on this machine. So Docker Compose is missing. I think that piece of software is not installed. So we need to install Docker Compose also. By the way, these things do not come by default on Ubuntu, on machines in the cloud. The formal method I will walk you through later on, it does come through. So that's what I am actually walking you through. Docker Compose, how do you install on Ubuntu? And that method is right there. So you will follow that method, and to get it on Linux, you have to follow first step like this. And then I'm just following official documentation, and that should succeed. So here we have some updates happening that should bring Docker Compose locally on that remote machine out there in the cloud. And that is setting up right now. And as soon as that finishes, one more command and we are off running. That should bring us Docker Compose on that target machine in DigitalOcean. So that machine right now that we have here, which is what we are looking at, that droplet called MyDockerBox, it has Docker, but it doesn't have Docker Compose. So I am adding that right now here. And there's 25 seconds left for it to finish off that action. And then we should have Docker Compose also. Once we have Docker Compose, we should be able to run Docker Compose whatever we like. And so that action that we just did was this second step, apply executable permission to the binary. I just did that piece also. That was here, was this command. And now that I have executed that completely, I should be able to move forward and test whether I have Docker Compose correctly installed, and I do. And I have Docker installed already, I know. And so now I'm able to run these exercises that we have in that folder. And to get to that exercises to run, we need to do a change. The change that we need to do is very similar to what we did here in the exercise before. Initially, all this write up was not there because that file was supposed to be empty as a placeholder. We need to fill it up. Fill it up with what? Fill it up with the stack of your choice. So our current choice that we have for our stack is, let's go begin with a simple example, which is the three tier WordPress stack. So that this stack, so we'll grab that and put that in a file inside the VM, inside that remote machine. And the file is called Docker Compose YAML. This file currently it is empty, oops, Docker Compose dot YAML. That file is currently empty. It has just this commentary. So I'll fill it up like that. And now we have a Docker Compose YAML file. Now what I want to do is just bring up the stack. So we have this Docker Compose YAML file, and we want to bring up a stack using this. So the way to bring up a stack is to go like this. And so we just bring up the stack. It should bring up the whole stack containing WordPress to bring it up on that IP address that we have this machine running. So it is pulling the images for MySQL and pulling the images for WordPress, and it should bring up the whole stack quickly. And you will see that it runs WordPress, as simple as that. And so that download finishes soon, and then it will run the stack and you will have it running. What does that do for us is that we will have this IP address showing WordPress right here, like that. And come on, one more time. I think we have to check the Docker process is running and finishing correctly. And we have WordPress running, MySQL running, let's check logs. And I think it is running now. So let's refresh. And that gives us WordPress right there. So we have it. That's how you do it in real life. You actually take a machine out there in the cloud, like this, like I have here. And then you install Docker, Docker compose, and you bring up your stack just like I did. What did I do? I ran this command, Docker compose up. So right now it is going to do nothing because there was nothing to do because it is already taken care of. Our stack is already up and running. So there's nothing for this compose up action to do. So it did not do anything. And then we have WordPress here running correctly. And what I want to do now is to delete the stack, to get rid of it. So how do you go with that? Just say Docker compose down and the whole stack goes away. And that means this site is not functional anymore. It would not work on that cloud machine here. We don't have anything running now. So we say Docker ps-8, nothing. It is cleaned out. The stack is gone. We will have Docker, Docker compose. The tools are available, but the site is not functional. It is dead. Next, what I want to do is talk about the idea of SSL, which is where you see this concept. Like I show you now, I think I showed you already is the idea of HTTPS here, this idea. So the concept behind this is, I think probably most of you already know this idea is what is SSL. You don't need to describe that unless you tell me otherwise, I will assume that you already know what SSL is and that you know about this padlock thing that shows you a certificate and all that good stuff. I think you already know that, but correct me if I'm wrong and I will not assume. I don't want to assume that you already know, but I'm going to make that assumption unless you tell me otherwise, in which case I will then describe what SSL is. But for right now, I'm going to assume that you already know HTTPS, that you know its importance and that you may not have actually created a certificate for yourself, but that's okay. That's okay. I will assume that you know what HTTPS is and you can see the difference right here in this example. So I'm going to go to your company's website. Your company website is Boeing.com. And you see this one is not HTTPS. It tells you right there. It tells you that the connection is not secure, which is unfortunate that you have such a site. I want to point out to you that this is a bad thing. Simply speaking, there's no other way to describe it. I'm just calling it out that this is bad. Please fix it. I know. Yes. I just said that. I'm calling out that this HTTPS is missing and I want you to talk to your internal people and fix it. And I'll tell you why. Since it is not HTTPS, by the way, there is an HTTPS version. I took a look at this carefully earlier today. There is an HTTPS version also, www.Boeing.com. It is a HTTPS capable and you have a certificate. So all you really need to do, by the way, the certificate exists. And here it is. Yeah. Yes. I see it. It is issued to Boeing IT, Boeing company and all that good stuff. It should buy digital certificate, global certificate authority and all that good stuff. And it expires on that day. That's fine. That's all fine. This is good. I'm not complaining about that. What I'm saying is this site without the HTTPS, without the HTTPS should not even open. That's what I'm saying. Yeah. I know you have HTTPS. That's good. By the way, that's a good thing. So I'm talking about this site, not the HTTPS site. This site should not even open. And if somebody tries to go there, it should be redirected to this site. This redirection should happen automatically like this, HTTPS, you should make it happen. If somebody goes here, HTTP, make it automatically redirect, then you're good. That's expectation. I expect your company to do this. You don't have to do it, but I think it makes solid sense to do that. People don't type HTTPS when they visit a site. People just open the browser like this and type Boeing and it opens to HTTPS. But if somebody says www.Boeing.com and hit enter, it did redirect. I think it is in my browser, I have HSTS implemented. That's why it automatically goes to HTTPS. In your machines, if you just type Boeing.com, it may not. And I think I showed you an example of the very first time when I opened this site. So let's go do that again with an HTTP explicitly called out and this site opens. Now I'll do the same thing with other companies. Let's go compare. So here is more companies. This window. Let's see if you can type www.Apple.com and see what happens. See automatically redirects to HTTPS. That redirection is a necessary thing. Let's go see one more company. How about www.b.a.cloudgv.us and try HTTP with that, explicitly try HTTP and hit and see what happens. See it redirects to HTTPS. That is expected. This is not expected. I want you to know that. I think you know that already. I want you to fix it for your company's benefit. If you don't fix it, let me tell you what happens. What could happen? What could happen is of some potential man in the middle, this is called MITM hack, man in the middle attack. That man in the middle attacker could potentially replace this website. You know, I think you have a sad news going there apparently. Something happened. So there is a sad news happening. So let's not talk about the sad news here. Let's talk about something else like this page. I think the only news there is the sad news today. So I don't want to talk about that idea. I would like to talk about something else. So let's not talk about this topic. Talk about something else. Is that you have a company like, let's talk about some other company. Forget this. Forget this company. I'll just generalize it. So let's not go talk about some incident that happened. So let's talk about some fictitious company here. So here is a fictitious company. Let's call it fictitious.com. And they sell this product called the letter F and they have a competitor. The competitor is, you know, genuine.com. And they sell a product called G and this fictitious company sells the product called F. So in theory and also in practice, a man in the middle attacker could hijack the traffic without an S. There is no S here. S is missing. When S is missing, a man in the middle attacker could hijack traffic and replace this F with a G. That's what I'm saying. And I can show you how to do that, the hack. It is super easy to accomplish. It doesn't take rocket science. And all you do is just follow these instructions here, man in the middle attack. You can potentially replace the picture of the product F with the picture of the product G from a competitor on this fiction website. If the S is missing, it is very easy to implement a man in the middle attack and your customers will get amazed. Why is G visible on this website? They will get shocked. And that is bad for your company called fictitious company.com. Just saying. So that's the fictitious example I wanted to give, which basically tells you the importance of this S. And by the way, getting that S or redirection and all that is super easy and automated. You just have to do it. I'll now walk you through how to make that thing happen. So the best way to do that happen is to, let's ask this question to Google. How do I get a SSL certificate? So they'll give you answers. And so here are some answers. So DigiCert company, GoDaddy company, these companies give you a bunch of solutions, right? There is a how to guide and all that. All of them are lame. You get advertisements. See that ads. They're all lame. Don't follow that. Instead scroll and don't follow the ads because ads are not a good idea. So what do we do now? We go look at links without advertisements. And the very first and second, I think the very second link that you see is the best thing you should go to. This link is a nonprofit organization, which is giving you a free automated and open certificate authority. This is the recommended solution. It is called Let's Encrypt and we'll use that right now in an exercise. So I am going to go to that location in that website and understand what this thing is. And so let's go read, first of all, see what this thing is. This thing is a free as in freedom and also free as in zero dollars, both are meant. This is automated, meaning you don't have to do anything. It is open, meaning it is open as in the standards are open and open for membership from other companies and all that. And so that is the underlying idea. The three key benefits of this certificate authority. The sponsorship here is huge. All the big name companies, you will find them in the technology domain. There are lots and lots of big companies that actually support this authority and it is a nonprofit organization. So there is no profit making going on here. This is a legitimate certificate issuer. When you don't know what a certificate issuer is, you should ask this question because I think in many of you may not clearly understand and know what is a certificate issuer, who issues the certificate, who are the authorities, why do we care and all that question. If you have such questions, you should ask that right now is a good opportunity to ask that. And so I will identify and of course you can ask these questions anytime you feel like. So here the certificate is issued by this authority. It's called Let's Encrypt. It was issued on 14th of December and it expires on March 14th. So you see the period here is 90 days, roughly speaking. That's how long a certificate is issued by this company, even for themselves and of course for everybody else. It is issued only for a strictly limited period of 90 days. So you will think that there's a lot of work because every 90 days you have to go and renew the certificate, but don't think like that because the renewals are also automated. So you have this automation built in into the whole fabric of using this service, meaning here let's go see this website and you will see that this website has a certificate issued by the same company. It is issued by Let's Encrypt. It expires on this date. It was recently issued apparently and I did not even know that I got a certificate renewed. You can see the certificate and you will find what it contains is the same level of detail issued by this authority on the January 18th and it expires in again 90 days. This is the name of the company that has the certificate issued and issued by this company. So who are these people that issue certificates and how do we trust them? Why does this lock show green color and when does it not show green color? Do you know all these things? Do you understand what is going on? Who establishes trust? Who establishes this trust relationship? Do you know that? If so, please tell me that you do. Otherwise I will explain this if you don't know. So please ask me this question right now if you don't know where that trust comes from. It's a critical topic to discuss in the idea of transport layer security or SSL certificates. You should actually understand this and I'm going to assume that you know. It comes from a certificate of authority, right? Sorry, say again? That comes from a certificate of authority, right? Right. But who are these guys? And this is like a relatively like two-year-old company. So prior to that, you know, who was the authority? Who has the authority? Let's get to that bottom line. Who has the actual authority to say that, you know what? This is green color and it's all good. And who has the authority, the authority at the foundation? Like these are new companies that pop up and there are like hundreds of such companies that will issue certificates. For example, let's go see some certificate issuing companies. So SSL issuers. And so let's see some examples. A VeriSign is one company. This is another company. And this is Entrust is another company. There are tons and tons of them. And so you will see that these companies will issue certificates. But who are these guys and why are they considered issuers and then who assigns authority to them? Like, can I come a company, come with a company tomorrow and create my own authority? Absolutely. Yes, I could. Let's see a quick example of that. So I will now go to this exercise. And where is that? I think I put it here. And so you will see that I will quickly generate a certificate for myself. And here it is. So I'll do this exercise for you to get a perspective on what is going on, who establishes trust. So here, a new folder, let's call it mkdir test. So new folder test. And there, actually, the folder was not necessary. So just go away. The folder is actually right here. Let's go to the quick exercise here. It's a fresh new exercise for us. And so it illustrates the idea of creating certificates and becoming an authority and all that good stuff. For now, I'm going to issue a certificate to myself. And I will be the authority issuing the certificate. So here, generating a self-signed certificate, self-signed, meaning I'm issuing to myself. This is US. The state is Washington. The city is Sammamish. The name of the organization is CloudGenius. The name of the organizational unit is IT department. The name of the machine is test.cloudgenius.us. That's the server. My email address is this. And then I have a certificate right there. And this is the corresponding key for the certificate. What I want to now do is just make some file changes, name changes to that one change, and rename this one also so it maps to, come on. So this one maps to the two files I now have are the certificate and the key. And I created them myself. So I am the authority. And so here, I can check my certificate. And here is issued to me, signed by me, here's the signature. Is that a valid certificate? Let's see if I can use this certificate that I have created here. In here, if I, hold on. If I use these certificates that I have and the corresponding key, if I use them with a website called test.cloudgenius.us, like I mentioned here, this site is called test.cloudgenius.us. If I use such a site with that certificate, will it actually work out okay? What do you think? Well, if you don't know, let's play with it. So I'm going to use these certificates, these exact ones that I just created, these ones, and I will bring up a site like this. And like one more. And you will see what's going on. I'm actually building up a quick site with that name and show you what happens when you use those certificates for real, in an actual case. I'm doing that right now. And it is finishing up. And you will see, I will bring up a new site called test.cloudgenius.us on the local machine. And you can also do the same exact exercise by being a certificate authority yourself and creating a self-signed certificate, self-signed, meaning you sign it yourself. Does that make you an authority? That's the question. Let's go find out. So I have a site running. I need to go one more change in my host file. This change will go into that file here, and it doesn't have that. I'm going to add one more line at the bottom in the etc.host file like this. Then I will be able to open my own test.cloudgenius.us in this machine. And what I will now do as a consequence of this change, you will see that I have this new line added at that IP address, so I will grab that IP address and open it up in a browser. And let's see what happens now. So time to test. So I open it up and say, boom, go. And nothing happens. So I need to go say, HTTPS, because I'm using HTTPS there, HTTPS colon slash slash and enter. And what happens now? Bad demo, is it? Bad demo. Let's see if the Docker containers are running. They are running, which means we should be successful in opening this. So let me just quickly check if we are able to open HTTPS colon slash slash test.cloudgenius.us and we should see something that is a bad certificate. That's the warning I'm expecting to see. Maybe a cleanup is needed. I think cleanup is necessary. So browser cleanup, I think is necessary. So I will do that. And history cleanup. Maybe it's a bad demo, but I'll make it run, don't worry. Well, I'm expecting to see this kind of a picture that you see. The connection is not secure picture. That's what I'm expecting to see, but I'm not seeing it. And you see the verification failed. So maybe the browser is not working, but you can see this verification failure. Server certificate verification failed. So that's what I wanted to demonstrate. I was able to demonstrate that idea without using browser, but with a curl command. So the browser is for some reason not functioning the way I expect it to be, but that's not the point. The point is I want to tell you that the certificate that I created that I have here are invalid. They're not recognized. I can become an authority myself by creating these certificates and I use them in a site and that site is running here. But then when I go to visit that site with curl as opposed to a browser, not using the browser, just using curl and I try to go there, HTTPS, I see certificate verification failed. So there is somebody who is verifying that whether this is valid or not. And my question to you is who verifies that, valid or not? Who's verifying here? Do you know? Somebody is doing that verification and it failed because these are certificates signed by me and I am not an authority. I can pretend to be one, but I'm not. So I created a dummy certificate that are signed by me and it is technically okay to do that, but then you don't have the authority. You can get a certificate that are invalid. These are called snake oil. There's a name for that, snake oil certificates, or you can call them fake certificates, or you can call them self-signed certificates. These are okay, but not really good for production usage because verification will fail. You can avoid that verification failure only locally by issuing a command, something like a dash K option, go like this and say dash K. So say dash K and then it will succeed. It will show you that it is running WordPress or running some sites. So the HTML opened up, see I disabled my verification because there is an insecure option. So I choose the disable, turn off the verification and now I see the HTML page, all that, hello world and all that good stuff. And so that's what you see. This whole HTML page showed up because I disabled my verification. So the question is, who's verifying these things? Who's the actual authority? Aren't there many, I mean, others are, aren't there many that need to verify? The more verification, the better, right? Yes, yes. But the origin of verification, like you see, I disabled verification right here. And so that's why it is able to open the page and that's good. But then I had to do this flag to call it say insecure, okay, let it come, let it come. And then it came. But the authority that verifies this or secure or not, for example, let's go see this one and you see verification failed. The authority that verifies this verification is the operating system. You mean, I mean to say this guy, the operating system that you're using, like it can be Ubuntu, it can be Windows, it can be Mac, it can be Android, iOS, whoever is the operating system, that is the authority. Now each operating system will carry a set of root authorities inside the OS itself. The OS carries a list of all the people that are considered root authorities. And that list is available in the OS. And I'll just quickly show you that list in this OS. And I'll show it to other OS also. So I'll just begin with this OS that we have at hand. And so I'll just get to that location where you can see that this OS stores its certificates in this location. And you can see that this is where it stores all the authorities, the root authorities. So let's go see full screen and read it a little bit quickly. There's not much to read here actually, just looking at a list quickly. So here in that folder called hcssl-serts, where you see this list, long list, about 200 to 300 entries. And here you will see a bunch of names, a bunch of old names. You can see that the authority name that you might find familiar are some of the names you might actually recognize, like for example, Komodo, Cybertrust, Deutsche Telekom, Digicert, and a bunch of Digicert here, DST. Remember, take a note that, take a very careful attention to this one name I'm going to point out to you. And that one is this one, DST root CA. So just pay attention to that. We'll come back to this one later. There are more, Dtrust, and a bunch of anonymous ones. And then the E-certification authority, and then there's Entrust authority, Eterga, GeoTrust, GlobalSign, GoDaddy, Hong Kong, Microsec, Network, OpenTrust, Cowardice, SecureSign, blah, blah, blah, goes on. By the way, you did not see any name of, there is Thotty here, Thotty. You did not see the name of usual suspects. For example, you see Amazon, but you don't see Microsoft, or don't see Apple. Do you see them? You don't see them. I don't see Apple listed here. I don't see, I see Amazon. I don't see Microsoft, but yeah, maybe I'm missing. Maybe they exist. Who knows? The point is these are the root authorities, all these guys. So from here, the first one, and there are all these names. So it goes on and on all the way to the end. These authorities are root authorities. They carry the root of the trust, and they carry that in that folder. That's where the operating system knows to go look for all the root authorities are stored in the Etsy SSL search folder. That's where operating system stores it. I mean, this one, this OS stores it here. There are other locations where other people store. For example, in Macintosh, you have this thing called keychain access. That's where Macintosh will store the authorities. So here you can see system roots, and expand it full screen, and you will see in here a bunch of authorities, root authorities. And Amazon, and Apple, and by the way, Apple was missing in the other case, bypass, and bunch of other comsign, detrust, and goes on and on. So long list, again, long list. Similar to this, you have every operating system carry a list like this, which contains the actual certificates created by the root guys. These guys are the root certificate authorities. And what they have done is pretty much what I did on my machine. I created my own certificates with my authority, and nobody cares about me. So my name is not listed in that root authorities, but apparently people care about these companies that are listed in the list that you saw. So those are the root authorities. And you will notice that these roots, or the root authorities, I should call, root authorities, do not contain Let's Encrypt, does not have that entry at all. And so me, in my website, in a browser, and I'll say HTTPS colon slash slash whatever that is, and I see that there is a certificate issued by this company. So when it is not in the root authority, then how come this is trusted? That's the next logical question. If you, Let's Encrypt, doesn't belong to the root, then how am I going to trust you? That's the next logical question to ask and think. So the answer to that question is that, imagine it like this, here is me, and here is Greg, and here is some person that I don't know, but I don't know. But let's call it Greg's friend is John. Let's assume that John is Greg's friend. So Greg trusts John, that relationship, trust relationship is established. Now I know Greg, and so I trust Greg, that relationship is established. So what the underlying idea is here that you go through a chain of trust. So I will call it transitive trust, transitive trust, meaning I trust Greg, Greg trusts John, and therefore I trust John, transitive relationship. That is one idea under the hood here in the establishment of a chain of trust, as it goes to all the way to your browser. So when you open something like, let's see, a browser, and you ask for the certificate for a website, say for example, HTTPS, and it should open the site and it is opening right now and you see the certificate and you open it and you say, okay, show me. So show me what you got. And it shows you the certificate and it is verified by Let's Encrypt, but who are you? Let's Encrypt. So you ask, who are you? And how do I actually trust you? So I view your certificate and I see that it is issued by Let's Encrypt, but do I know you? And so let's go to the details. And so we see the details that this certificate was issued by Let's Encrypt, but Let's Encrypt themselves have another certificate issued by this guy, you see the chain of trust. And you will remember in my listing early on in the root listing, I specifically pointed out to you this guy, which is the authority that issued a certificate to the Let's Encrypt authority, which in turn has issued a certificate to this entity. And so there is a chain of trust established like that. That's where the chain comes from. So the root, there is a root cert. And in every operating system, you will have a set of root authorities. This happens to be one such root authority. So it is beginning from the root so that the OS knows about the root because the cert is stored in that hcssl certs folder. That's where Linux stores it. And so the certificate for DST root ca x3 is sitting right here. The OS knows and trusts it. So that is established already. So this is good. Now we see in this certificate that there is a chain here. So the chain is like this, one, two, three. And that chain pretty much tells you that this is a dependent certificate. So you get this certificate from here and this certificate from here. And that's the DST root ca certificate. So that's how a chain is established. As you can see, go in detail inside a certificate like this, you can see the chain like that. And that is why the browser is able to say, yes, I know and trust what you're looking at. And therefore this green color shows up. If you don't have it like that, it will show you a red color or something bad, which I wanted to demonstrate visually, but I could not. So I'll give you one more time and attempt. And I hope this pops up, but apparently not. It's not popping up in the browser for some reason, but I don't care too much because I was able to show you on the command line. It's a kernel browser, not this browser, other browser. It's fine. Same thing. I have a question. Do those root certificates change periodically? For instance, if there's a hack of some sort with Komodo, for instance, Apple could take them off the root certificate list. Yes, exactly. That is exactly true. You're thinking in the right direction. This is exactly how it happens. And that's what happens when you update the iOS. So when you update the iOS, a new update will come, update Ubuntu, a new update will come, update Windows, some update will come as a part of the updates from the operating system maker, Ubuntu or iOS or whatever OS is. Every OS is backed by some entity. I call them the OS maker. This entity can be Apple for iOS or Ubuntu for Ubuntu OS. But basically it's the Linux kernel, which is Mr. Tor Worlds. So that guy controls it. And we trust him because we have no choice but to trust him. And so that's Linux. And that's where this kernel updates when they come, they come along, they bring along new roots certificates, they sometimes add new ones and delete old ones. So that change keeps on happening. And that's where the chain of trust is kept clean and authoritative. So anytime an OS updates, you get fresh certs. Some get added, other get deleted, other gets modified, other get updated. All those things happen when you get an update to the OS. It can be Android coming from Google, which is also by the way, under the hood it is Linux. Same thing. And so that's where it is coming from. Of course, companies like Google can add extra certificates on top of what Linux does. And so there's going to be additional certificates popping up. For example, you saw here in the key chain, you see some Apple certs. Apple certs show up. They are, where are they? Here are Apple root CA, Apple root CA2, Apple CAG3, Apple root certificate authority, like that. And Microsoft, I don't know exactly where Microsoft Windows stores the certificates, but it's easy to find. It's just a Google search away. You can search. If you're using Windows, you can say, where does Windows store the root SSL certs? And question. So it will tell you the answer. So here's the certificate directory where it stores. So you can see certificate database and you can see all that. So you can read where Microsoft stores. And to give you the exact answer is right there. That's where it stores. So you can say the database is contained in the system root system32 cert log folder. And that's where it contains the issued certificates, the revoked certificates, archive private keys, certificate requests, and all that good stuff. This is the certificate directory in Windows. Same thing with every OS. Every OS has the same idea that you have to have a set of roots, the root certs that will actually validate through a chain of trust up to the last point where you have somebody like this company claiming to be having a valid certificate. And that claim is validated by the OS. So this claim is actually validated by the OS looking at the root cert, which in turn looks at this cert, which in turn looks at the cert issued to my company. And that is what you're looking at here. So that's a chain of trust idea. Having seen this idea, let us implement this idea for real in a example case. And so that example is what I will now run in our setup in that box, in this Docker box that I have here, that one. So I want to run that as the next example that we will create. But before that, as you know, we have to have a domain name pointing to the box. It has to be a valid domain because a certificate can be issued only to valid domains. So what I want to do now is choose a domain name first. So you have to go something like your domain that you have, and you have to come up with a name. So I think in this example, I have the name called some other. That's the name I have chosen, apparently. So I will take that name, go to my DNS company, which is Cloudflare. And there I will log in and then create an address record for this machine. And so here is my login, and here I log in, and I like to remember me, and then I put in my two-factor, and then I log in, and then I will go to the CloudJS website and the DNS, and there I will create a new record, call it some other, and let's see if it exists. Apparently, it does. So there's some other exercise I did some day ago. So I'm going to remove that record, and I'm going to actually add this IP address right there, here. And when I do that, what happens here is that some other name gets pointing to that box. That's what I want. That is a necessary step. That's how the certificate authority that I will be asking a certificate from will know that I am the right owner for this box and the domain. So the domain validation and authentication will need to succeed before a certificate is issued. So let's go read this a little bit in what I just did. So I'm going to go to that location called Let's Encrypt. And here, for this company, this agency, which is an open certificate authority, for them to issue a certificate to this site that I'm going to create, by the way, it's called some other.cloudgd.us. It points to an A record, which is this IP address that I just, whatever I have, the DigitalOcean IP address. So it points to that one correctly already. So that A record relationship in DNS is already set. That is what will be validated before a certificate is issued by this open authority. And it will be provided to me, and it will become visible to us, and we will see it. We'll actually see a green color padlock when I visit ahttps colon slash slash. This S is where you will see the green padlock showing up on this domain, which is currently pointing to the box called DigitalOcean right here, this box, which means our DNS should resolve with the dig command, which means dig. And then, hold on, what did I just do? Oh, you see why that thing was not working? I was running the exercises in that remote box, not my local box. That's why it was not working. Do you see the problem? I was assuming that I am running locally, but I was not. And so that was the problem. So you can see that I can fix it now, and you can see the invalid certificate, I guess. Yeah, we should now see that. So let's see if I ping it correctly, dig test.cloudg.us, and it goes correctly. Nice. So let us see if we can actually, https colon slash slash test.cloudg.us to see the invalid certificate popping up right there. So that's what I wanted to show you visually. Now you can see it. It tells you that there is this site called https test.cloudg.us is actually an invalid certificate. You can actually read the whole thing. It will tell you exactly what's going on. See what I'm doing. And the mistake I did, apparently, is I did not pay attention to where am I running. I ran the whole exercise in Docker box, which is in DigitalOcean, which is fine, nothing wrong with it. So now I have a record that maps the test domain to that box. And I'm going to say https, this is an https request to that domain. And it says connection is not private with the red flag. And it tells you somebody's trying to steal your personal information. You should go back to where you came from, go back. But I know that this certificate that I have created in that folder, that I know these files that I created myself, because I am the authority for that certificate that created it. So I know that it is me who is doing that. So I can inherently being fully aware that I am the one that created that certificate. I can say, you know what, yeah, I want to check the certificate. So I will view the certificate and I will confirm that it is indeed me. And then I will visit the website. So I'll first of all view the certificate and then visit the site by overriding and say, I don't agree with you because I know this is the one I created here. And so I'm going to visit the site and you can see that the padlock here, green color will actually show with a cross. So it will not show the valid padlock because the OS still doesn't agree with me, but it lets me see it. So you will see now I will actually view the certificate. It will show me exactly what I created manually. So here I'll say, okay, show me the cert. So here certificate opens up. You can tell right here that this certificate was created by me. And you can see my company name, Samayamesh, Washington, U.S. That's what I wrote in the form that I was filling up in the browser, the IT department, my email address pops up. And this is a part of the certificate issued by me. And I am the root, but I'm not, I know I'm not a part of the OS root, but I am root for me. And so that's the invalid certificate. It is considered invalid because OS doesn't agree. I can take my certificate and drop it in the Etsy SSL certs folder. And then OS will agree, but I don't want to mess with my OS. So I'm not dropping my cert here, but instead I'll keep it separate in a separate folder like this. It's a different folder, not that, that's the OS folder. It's hidden and not protected folder. I don't want to mess with it, not messing with the OS, but this is where I have the certs. So it is showing up and is presented to me. And I am going to now having verified that this certificate is actually the one that I created. So I've seen the cert. Now I understand the risk. So after having understood the risk involved, I can now visit the site. So here we go. Click and you will see the site. And so maybe it's, maybe this, this exercise is done better in Firefox browser. So I'm going to cut this and go to Firefox and you will see the same thing. I think it is done better in this browser. So you will see now the same thing, connection not secure. It's very elaborate in the way it describes. I think I like the reason I like Firefox is because of this idea. It tells you very explicitly what's going on. The owner of this machine has configured their website improperly to protect your information being stolen. Firefox has not connected to this website. And so you can report this error to Mozilla and so that they will block me and all that good stuff. But I don't want to report because I actually want to see, I don't want to go back. I want to go advanced. So I see the advanced section and I see that this certificate is invalid because it is self-signed because I signed it myself. And so that the error code, self-signed cert error code, I can add an exception to it now and say, no, I want to see it, man. Come on, let me go. And so I say Mozilla Firefox, please add an exception. So Mozilla says, okay, let's get the certificate. So view it. And I see the certificate issued by cloud genius. So you see, issued by and issued to both are cloud genius. That's the point of observation I want you to make. You should buy me, issued to me. And that's me being authority for myself, which is understood. So I know this is me. I know this is a certificate he created by me. So I'll say, yeah, got it. So confirm the exception as soon as I confirm the site opens up. It opens up and just like I expect. And here is the flag that you can see. It is not green. It is yellow. This flag is yellow indicating it is a self-signed certain. You know what you're doing. So I'm letting you see it. I'm letting you visit the site, but this will show yellow. And that yellow basically means the connection is still not secure. I mean, it always doesn't agree. I let you see the site always does not agree. You can remove the exception and the site will disable, disable, immediately go back to how it was to begin with, not secure. So that's the concept. Having seen this idea in actual example, I will now go back to our VM and break that whole setup. So this thing is running Docker PS-A. These things need to be broken. So I'll break that right now. I hope you understand what I'm doing. And if you don't, then please ask questions. But if you don't ask questions, I don't know whether you actually understood or not. So I have no idea, honestly. So you need to please ask questions. If you don't understand, this certificate thing is tricky. I just want you to know. If you don't understand it, you will feel at loss, complete loss as to what just happened. And so I have created these two certificates that are created by me and they are self-signed which you understand now, I hope. And so I'm going to delete that. So it's self-signed certificate here, RM-RF, SSL, whatever that thing is, gone. So my created certificates are gone. And I have the test folder that I have here. What do I have there? Nothing. So I'll remove the folder. And I have no certs and I have just the Docker files folder. So I'll go inside there in that folder, Docker files folder, and there I will find the folder structure that we're playing around with the exercise. That folder is sitting in here. So we ran the three tier WordPress example before you saw it already. We destroyed it. Then we saw the self-signed certificate example and we destroyed it also. Now we will actually create a properly signed SSL certificate pointing to the same box, which is this box called my Docker box. And it has dig to some other, and it points to the same IP address. So the name I will be using is some other name, it's a different name, same box and nothing running right now. So you see there is nothing running right now. And so what I want to do now is to actually run something inside that gets me a properly signed certificate and that is this example. So I'll grab it and I will also talk about it in greater detail. I just want to run it quickly. So what that example does is that I need to fill it up in our Docker compose YAML. That is the basic file. So I'll open it up, by the way, sorry, open up, do it again. That file needs to be edited. So it has this data that needs to go away. And what I need to grab from on the left side is what I will bring and paste like that. This came from the left window, which is this file called let's encrypt, Docker compose let's encrypt dot YAML. That's where it came from. It is also locally available to you, but it's easier for me to just show you and copy paste. That's why I opened the browser on the left side. On the right side, I have taken from the left, put it in the right file. And that file is that file, which is called Docker compose YAML. Having seen that file, let's get it. It contains the let's encrypt example copied from this file on the left side. Having seen that file, I will now bring up the stack. To bring up the stack, I have to go Docker compose up. So I'll go do just like that. And what you will see as a consequence is something to discuss. So first thing you will see is that there are four pieces to it, one, two, and three. But where is the fourth piece? That fourth piece is missing. So that is what will actually get us the certificates. So we'll have to accommodate them also. They're not in this example. That is I think in a different example file in the same folder. So those two pieces are I think in the step-by-step. That is one piece and where is the other piece? I think it is better written in this exercise. So yeah, this one is better to follow. So I'll just follow that. Instead of this Docker compose YAML, I'll just switch to this exercise with a demo of HTTPS server. That's a much cleaner way to handle it. So we'll close that folder out. Instead, we'll just stick to the website description in this lesson, which is what I'm going to follow now. This one will give us a demonstration of remote HTTPS server. The result will be that we will have some other.cloudgme.us popping up. That's what I will now demonstrate. For that to work correctly, we need to have a bunch of things in place. First thing is that we need to have a method to systematically get a SSL certificate from this authority. It's encrypted. So we need to have a service running here in our box that goes to that authority and grabs or requests a certificate. We have to have somebody request a certificate to them and then they will validate. Are you the rightful owner of this domain or not? The validation happens through an A record check. That A record check happens and that will succeed because our record, some other.cloudgme.us actually correctly points to this IP address, which is this box, which is the DigitalOcean box. That validation will succeed. As soon as the validation succeeds, then these guys will issue a certificate here. You go. They give us a certificate, so we'll use that certificate into our setup. How will our setup be looking like? Let's go look at that design first. In our setup, that's the process. The flow of getting a certificate is go request, they validate, we succeed, and they give us a certificate. Then we use it to use, use the cert. That's what we'll do now. That's the sequence of actions we need to make happen, and we need to make that happen automatically, without us getting involved. For that to actually work out, what we want to be able to do, sorry, I think I just stopped sharing for some reason, accidentally, so I'll share again. For that to happen correctly, what we need to have is in our box, we need to have a proxy, and we run our service here, whatever we want to show, that we'll run here, and we'll map our port number 80 to the proxy. The proxy will run on port number 80, it will map its port to the port number 80 of the box. This is the box. This box is an IP address, and we just map to some other.cloudgini.us, that's the domain name. That is the IP address mapping happens already with an A record in DNS A record. That mapping is clear. We need to get a certificate here, loaded, and so the DNS record is already checked. We have checked that already. This is the box. The box has a port, port number 80, and it needs to also have one more port, open 443, that should map to the port of 443 of the proxy. This 443 is where HTTPS actually works. HTTPS works on port number 80, but HTTPS works on 443. That's the box port 443. What we need to do is to run whatever we want here, and expose the port number 80 to the proxy. This guy might require a database, and might require other things, but those are hidden. They're all self-contained in a service, and all we really want to expose is this port number 80 to the proxy, so that whenever somebody asks for this, it will go transport that over through the port number 443 on the box, to the port number 443 on the proxy, and then the proxy hands it off to the service, and then it shows what we wanted them to see. That's the game, but then where does the certificate come from, and how do we receive the certificate, and who will actually handle the interaction between the authority and the box? For that, we have to have one more service, and that service is a helper service. This helper, also known as a companion, is what we need to run in a separate container. Now, if I redraw the whole diagram again, one more time by clearing up my design, and I'll draw the whole thing again quickly, is that we need to have in our box a proxy that maps 443 to the machine 443, like that, and this is the proxy. We need to have a companion that talks to this companion. All it does is talks to this agency and gets a certificate. Now, we have a service running here that exposes port number 80 to this proxy, so that proxy talks to 80 to us, and we can have whatever we want to run, that runs actually here, here. We need to have whatever we want to run here, and a proxy, and a companion. We have to get these things available out in some containerized services and run these containers in our Docker box. This is one thing we need to run, this is the second thing we need to run to get us the certificates, and then we can run whatever we like, whatever else we actually run. We run here, like WordPress or some other service, that's where the application runs, and it exposes port 80 or some other port, and then this will handle the transport, and this will get the certificate. There is a solution for this available called Nginx Proxy, Nginx Proxy that you have used before already, and there is this companion also available called Let's Encrypt Companion for Nginx Proxy, slightly longer name, so I'll go look at these solutions out there in Docker Hub first right now, or GitHub. We'll go to GitHub and see Nginx Reverse Proxy. The first solution that pops up is I think Jason Wilder's on GitHub, so let's see GitHub, and there is Jason Wilder's proxy. That is this proxy that I will be using, that's one piece. Second piece that I'll be using is a companion, and so that proxy will be on GitHub right there, and this is the proxy companion that I'll be using as the second piece, and then the third thing that we will have is a bunch of services, so we'll go back to our website, and here what we are going to do right now is to actually start the proxy like this, and this will start a proxy server, Nginx Proxy, right in our Docker container where we have nothing running, and so this starts a proxy. The proxy is now running. You can see it, and what it does is also tells you how the mapping is happening. This tells you mapping between AT on the machine side to AT on the container side. This tells you mapping on 443 on the machine side to the 443 on container side. That mapping is already established here, and that is running your Nginx Proxy, and it has certain volume mappings, and it runs Jason Wilder's Nginx Proxy. That's what we just discussed. That proxy is now running. We'll now have to get the proxy companion, which talks to the Let's Encrypt website or the service that issues certificates. It is a free non-profit open source authority, and every other authority that exists is rendered meaningless as soon as this thing came along, which is the dominant certificate authority today. Dominant, because first of all, it is $0 free. Second, it is open source. Third, it is backed by the community, and fourth, it works out fail-safe, absolutely fail-proof every single time. It automates itself. You don't have to do a thing. It is completely hands-free and automatic, so it just renews by itself every 60 days or so. The certificate is valid for 90 days. Having seen or at least understood that piece, I will now instantiate a companion. The companion is available to us from this location and GitHub. We'll grab that companion and run it like this. Here is the companion run. Let's go to invoke that. The companion starts now. It's not able to find the image, so the image gets pulled, and the companion is about to run now and is running. We go to examine that. Here is the companion container that helps you get a certificate. Both are running. Anyway, you will see that this companion does not expose any ports. That's the companion container, and NGINX Proxy does expose those ports, 443 and 80. The companion doesn't. There is no exposition of ports, but what it does though, sorry, this is not the right. This is the companion. This is your companion folder, and this is the actual application that we want to run. The companion is here, and what this one does is there are no port mapping, there's just a volume mapping here, two volume mappings, and that's it, but it handles the certificate transactions for us. You will see them in action as soon as we kickstart an application. We will now run some application in the same set of containers, in the same box we have. Here is the application. We will run it now, and so we grab it and run it, and it is running, and that means we have three containers running. Let's go see them. The three we have running are, the thing I just mentioned, same thing, quickly reviewing them one more time. You will see that I have started a new container here, running the application, and it is exposing its port number 80, but not to the machine, just on the Docker container infrastructure. The machine doesn't know about this port. The Docker container system knows, so this proxy is able to communicate to that number 80, but the machine cannot directly interface with that because the machine port is not mapped. This port for the container called nginx-proxy is mapped, machine to the container, machine to container, machine to container port, and that mapping has happened, but here there is no machine mapping. It's just the container level exposing the port, that's it, no mapping. Just expose for the application that we just started. What this looks like in a picture illustration will be like this. From a diagramming perspective, it will look like I have a box. I have a container called nginx-proxy running, and I have a companion running, and the application running here. This exposes 80, and this exposes 80 and 443 to the machine outside, and it's able to talk to me. That's what we have. There are a bunch of volume mappings. This companion container will then interface with and have a certificate issued. Now, let's see where the certificate is issued, and how it is issued, and where it shows up, and how does it actually manifest from a real example perspective. We will check. What we want to check is whether something opens up on that location. Some other.cloudgigy.us. Let's see what opens up there. We'll go, first of all, check our logs. We'll check the companion logs and see what we have. The companion container has this ID, so we'll say docker logs and companion number. We'll see some ID here. Some logs here are coming up from the 20C container. The container ID is that number. I'll say, show me the logs for 20, this 20, I just picked up 20 and put it right here. I see docker logs for the companion right now, and the first thing I see is generating a private key. It's writing the private key, creating a default certificate had been created in that location. There is Diffie Hellman Group is running in the background, it pre-generated a key being used. It takes a long time to save prime number generation. It's reloading the NGINX proxy, generated a new configuration. Then it says, watching docker container events, and this content did not change. Then what happens? Some event started because this container new app started apparently. This 61 number is the application that I start. It gets a notification of a new container app starting. This app that I created, this number 61 comes from that one, which is the app, which is what we are running. That shows up and it receives an event notification that you just started a new app. It's going to reload the configuration. It's going to create reloading the NGINX. Now it did not see a change, keeping notification, another signal process received. Then we have generated data for three containers. Now that we have three containers, one, two, and three containers running. Then it says, I need to get a certificate for this domain. It asks for that certificate, signal process started, creating a renewal request. The renewal request for this domain created. It generates a new account key, and it's using simple verification. It's implied that you agree to the certificate authority's terms and terms of service. You indicate agreement there. The agreement that you just signed was this PDF file. You can read it if you like. That's an agreement between the certificate authority and you. It generated a new private key. It got the certificate issued to you. It saved that certificate files in that location. It reloads the NGINX proxy. Now you have the container idling again. It is now idle. The container is doing nothing until it gets another signal. It watches for events. When a new service starts up, it will try to gather a certificate for that new domain. This portion indicates that we now have a certificate issued to us from Let's Encrypt for this domain. It is applied already. It should be functional. Let's go check, see what happens. I will now, after having seen the logs, I will open Firefox browser and go to some other like this. Let me erase my ink. I'm going to go to some other.cloudgenie.us and see what happens here, https://someother.cloudgenie.us. And it pops up with a green colored flag. And let's see what it shows. So with the green flag, you can see this flag. Come on. Mouse. Yeah. So let's go see the certificate. More information. View the certificate and let's examine what do we have. We see that the certificate was issued by this authority today, today is 25th of Feb. So today it was issued right now actually, and it was issued to this domain. That is why you see this is green color. It will expire in 90 days. But then in this 90 day period, as it begins from today all the way through 60 days from now, this companion will get another notification saying, hey, only 30 days left for this certificate to expire. So it will kick another renewal. And so it will get renewal fresh for 90 days starting from this date all the way here, 90 days. And then it will start the counter to zero and then all the way up to 60 days. And it will get another notification saying, go renew your cert. And the renewal will happen automatically again for another 90 days. And then it will start the counter again for 60 days and then renew again. And that renewal keeps on happening without you having to do a thing. All you worry about is whether your applications are functioning or not, whether this thing that you created in the app that you created here, is that working? That's the primary question that you could address. Is this functional? Is this working? That's what you would pay attention to because this part is not only free and open and automated, but it's like completely automatically renews itself. So you don't have to worry about it. That's the whole point. And that's the exercise. We can just now swap the application under the hood. And what I will do now is remove this hello world thing and say, you know what, get rid of this. I want to put some actual real functional application right there. So what I will do now is go look at my containers. And I have the Tudum Apache 2 Apache container. That one I don't like anymore. This app is bad. So I'm going to remove it. So what I'll do is Docker RM 61, 61 dies. So 61 is dead, which means nothing will open here now. So I refresh and boom, nothing opens. That is expected. I killed the app. My container is running, containing my companions and the proxy. Those two are running. Nice. Now I will go to the Docker files folder and there I will have a bunch of things that I can play with. So this is just my experimentation folder. Now in there, what I would like to do is to take another example and put that example up and running in our scenario. So what I would like to do now is to bring up another example. And the example I would like to bring now is, let's see if I can pull up the right segment. So the example I want to bring up as opposed to the Tudum Apache, which I just killed here, is a different one. And that is, is it this, no, what about this? The same thing. Now this, that's the one I want to bring, yeah, that one. So that's the one I want to bring now to Docker. Let's encrypt. Come on, open the file, please. Yes. Yeah, that's the example. So what I want to do now is just quickly check, what do I have running? I have a proxy and a companion, but no other application. Now in our Docker Compose YAML, what do I have? The same thing that I have on the left side. This left side contains a data segment, which is where I will store the database data like here, store the database data, and that runs MySQL image. And that is the same thing here that you see is here in this example. And this is running the WordPress application. That is the same thing you see here in this segment. So it's the same content. And what I'm going to do is these three containers, one, two, and three, I want to start them up, but I already have two, companion and nginx proxy. So two are already there. I will start three more, one, or I should call it three, four, and five containers. That will be total five containers available to me. This is two and this is one. So one, two, three, four, five containers I will now have as soon as I bring up this stack. But this stack is not running yet. So I will need to work towards getting to run. Getting this to run is simple as Docker Compose up. The stack gets up and running. And you will notice here in this stack, there are no ports mapping to the machine. The machine does not directly connect to WordPress, does not connect to the database. It exposes WordPress on port number 80 and proxy will pick it up and show you. That's what you will expect to see. And now we will bring up the stack. To bring up the stack is simple as this, Docker Compose up. So we'll run it and it brings up the stack and it's pulling something. It's going to do its thing and then we have a total of five containers running. So let's see what we have. So the five containers are now running and we'll see them and here they are. So the first one is your proxy. Second one is the companion. Third one is the data store, place to store data. The fourth one is the database. And fifth one is WordPress. So those five containers are now running. You will see that the WordPress container exposes itself on port number 80, but it does not map to the machine like this. This one is a machine to container mapping. This one is a machine to container mapping, but they don't. They just expose only the container open ports. This is for WordPress application. This is for MySQL database server. And this is the place to store data, the data place. This one is a companion. It doesn't need a port exposed. Companion does not need a port. So that is not necessary. That's what the layout of the land is. We have five containers running, which means we have a WordPress site running on the same location, which we had that totem thing running early on, which means, and by the way, it will be supported with HTTPS. It will be reusing the certificate that was already created because we have a valid certificate and it is going to be assigned to the WordPress site now. So let's go check it out. Come on, this way, 50% screen, there we go. And let's go open the Firefox browser one more time. And I like Firefox because it actually gives us a very clear signal and descriptions are very nicely written the way I like it. And that's clearing out my ink and then reloading the same site, which was apparently not secure. Now it is only secure. And so here we have WordPress with a proper certificate. We can fill it up and actually set up the whole site and make it functional just like you would expect. But that is not the point. The point is SSL and it is valid and it is issued already and it did not renew. This one is not renewed because there was no need to renew. It was issued correctly today and it is reusing the certificate that was used from the previous example because we did not actually kill our containers. This proxy companion and the proxy, they are still running like 13 minutes ago and 15 minutes ago. Whereas these guys are like nine seconds and six seconds ago, eight seconds ago. So they reuse the older certificate. That's what this certificate is issued already. So they reused it, did not destroy the certificate. It was kept in the companion. It just reused because the domain name happens to be the same, some other same name. So that's this idea that I just described to you in the same series of exercises that we have in our Docker files folder here. And I think there is one more, which is the eight containers. So let's go grab this and see what we can do with it. So here is the exercise. It's just a point of illustration, nothing much. I think you already understand the concepts, but I'm going to quickly run it just to round out this concept of using Docker files in real life machines. And so what I need to do now is to bring down my stack. So I will kill specific containers. Which ones? I want to kill DockerRM, I want to kill the WordPress, sorry, hold on, not like this. I want to kill the WordPress container, oops, break, I think I typed something else. Do it again, Docker PS-A, and I want to kill the WordPress container like that ID. And so DockerRM-F that ID, and then I want to kill the MySQL database container. And I also want to kill the Docker files data, that should also die. So that dies, three containers dead. So now we have two running only. Those are the proxy and the companion. In this elaborate exercise, which I don't actually have to do because I think you already understand the concept. So we don't have to do it. We can move on to other topics, which is what I intend to. And so, but I will quickly give you an understanding of what this exercise is going to be. You can run it on your own. The point of this exercise is the last file in the same set of files in that folder, which is the Docker files folder. It has the last file called other examples. And in the other examples, what we have is just a bunch of different applications all in one common Docker compose YAML. And that is the data file, which gives you a place to store the data from here. And then it has a database like that. It has a WordPress image. It has another WordPress image, independent standalone, standalone WordPress. This is three part, one press one, two, and three parts. This is all in one WordPress, and this is another one in one WordPress, another of the same. And this is Joomla. This is Redmine. There are more. There's a whole list, and you don't have to run it, but this example merely illustrates that you can, and here's how you do it. So I don't have to run it. There are, I think, two or three Redmines and different applications included. So there's a Redmine, which contains an image that connects to Postgres here. And then there is another Redmine, which links to the same Postgres, and there's a Drupal image also. So a bunch of different, I think, six or seven containers, different services running in one common Docker compose file, and an additional set of examples for you to play with if you are interested. That's the exercise that you can do on your own. I don't want to run it, actually, because you already get the concept. And I hope you get the security concept most clearly, which is the SSL idea here. And so anytime when you run into this scenario that you are wondering, how do I get a certificate? This is the right recommended way. There is no other way I recommend. And this is sponsored by major companies you can think of. So there is all the big players. You will see them here. It's a long list. Everybody is sponsoring them, and it is the right direction to go for future. Not spend $800 SSL cert from VeriSign. You can buy a certificate for $800 if you like to waste your money, and you can go to somewhere like VeriSign, and let's see, where's the $800 certificate? I'm looking for it. Yeah, they will sell you $800 certificate if you want to spend that money, but there is no point. Bottom line is there is no point. But let me show you one, there is one more idea that I want to highlight, which is an extension of the SSL certificates called EV, or Enterprise Validation Certificate. A slight extension that is something I want you to pay attention to that you can see here as an example. Oh, they stopped it. Huh. Okay. They used to have an EV SSL here, and now they are using a simple certificate. Okay. Who uses EV SSL? Let's see. Citibank? Maybe? Citibank? No, they also stopped it. Apparently, all the banks are also stopping it. Do you know what EV SSL is? Enterprise Validation SSL certificates. If you know that, please tell me. If you know of an example, maybe this is a good example. No, even they don't use it. So who uses SSL? Who uses this Extended Validation SSL certificates? They themselves don't seem to use it. No, they don't have an EV SSL. But who uses that? Chase Bank, maybe? No, I think it is going completely out of style. Most banks used to use it. Not anymore. Apparently, my mortgage company used to use it. Let's check that one. What's the name of the mortgage company? I have no idea. Sorry. I have no idea what the name of that mortgage company was. Apparently, I used to have an account with that, but I forgot their name, but who cares? The concept of this EV SSL is to give you an extra level of comfort with SSL certificates. Some extra level of comfort that I'm not able to immediately demonstrate. But if you happen to know of such a thing, let me show you what I mean by that. Sometimes you will open a site, it will very, maybe Mint shows, mint.com. Yes, yes it does. So here is an EV SSL example. So this is the site called mint.com, and here is your green flag. It is not just a padlock, but an extended name. And that is one example of an EV SSL, extended validation. That means somebody went ahead and not just use automation to validate whether this domain is owned by this company, but actually made a phone call, looked at their records and some other verification of extra verification, extended validation certificate is something that is a flag in the SSL certificate itself that gives you this string that shows up as the owner or the rightful owner of this domain, popping up with the name of the company here. And that is your EV certificate. This is going out of style and not so popular. You saw many banks used to use it, they don't care anymore because it is actually kind of pointless. It actually leads to confusion, am I going to Mint or am I going to Intuit? That's a confusion right there. So you don't want to have that scenario. That is kind of confusing. So I actually don't recommend this, but then it is available. You have to pay like $800 for this to make happen or something like some exorbitant amount of money you have to waste, which doesn't give you anything much. You can get proper security directly without spending money and in an automated fashion from here. This is what I recommend and nothing else. So don't waste money. Go here and you can validate that with Google search. So SSL search and you already saw that. I think most of the things that you see first are advertisements. So you don't want to pay attention to the ads, go straight down and the first thing you will see is not these guys. I think even Google has to catch up, but yeah, there are free SSL search right there. This is the authority. I want you to remember that and use it. This is open source. Having said, we will now switch to the next ideas, next set of exercises. With that, I think we completely flush through the concepts in that set of exercises called Docker files exercise. With that, I will just destroy this droplet and because we are done with it, we'll move on to other exercises. So here it goes, that droplet dies right now and say bye-bye. So this exercise we did with Docker files is something that we ran through a bunch of exercises in two different places. One of them is this one. So this one was like right up here, use your own domain. So that's where the local demo was and this one is the remote HTTPS demo. You can run the local demo locally on the VM. I accidentally ran the local demo remote and I did not know I was doing it, but that should not confuse you, I hope. This one is a remote demo that you saw me run in that site called some other. With that example, I will now move on to understanding Ansible and using Ansible and then we will use Ansible to set up a cloud infrastructure ready for use with Docker. So we don't have to do it manually and don't have to do it the hacky way, but instead do the recommended way, which is recommended by the Docker company and its documentation. So that's the documentation I will execute. And I just said this word, which you probably noted, execute documentation. That's kind of oxymoron. I just said execute documentation. So it is the idea that I think I want to get to, to help us understand what is executable documentation. It is basically the kind of design that I'm describing to my applications and my tools to tell what I really want to accomplish. So it is very, very similar to the idea of using Chef is where the idea of using another tool like that called Ansible. And that's what I'm beginning to discuss. And I will describe this tool, I'll help you understand what this thing is. It is conceptually very similar to Chef and most other tools like that, because what they really do is accomplish your desire. And if you recap what we had at the beginning of our Chef discussion is the idea of defining what you desire and you write that down in some location, you call it kitchen, and in here you will call it a folder or you can call it whatever you like. But that's not the point. The point is you have to be very clear about what you desire and you need to write that desire down in a location. So we will use a folder to write that desire. And in case of Ansible, just like in case of Chef, we have a repo in Chef. In here we just use a folder. We have some configuration here like the.chef folder and then there are NaiveRB file inside. You have similar things here. In the folders, there are some files that we'll talk about that briefly that stores the configuration. In here you have your cookbooks that describe and do stuff. The same idea here in case of Ansible, this is Chef, that is Ansible. The idea of Ansible here is that you will have do stuff is written down in playbooks. This is written in Ruby language, this is written in Python language. Both are good. It's also awesome. It is a little bit different. There is a Chef and a Chef server. There is no such thing here. By the way, these days there is a thing called Ansible tower. Ansible tower is available for subscription, so you have to buy it from IBM, Red Hat. Red Hat was bought by IBM and Red Hat bought Ansible, so now Ansible was a Red Hat product, now it is an IBM product. For big companies, you already have Ansible tower, so you can use it. It's a commercial product, so I'm not going to talk about it, but you have access to it, so you should be able to use it if you like. This Ansible thing does not require any installation. That's a great thing about it. You have to install Chef. You have to install Chef before you use. In case of Ansible, you don't have to install anything. That's the beauty. It just works with whatever you already have. There is a Gotcha though, so I will call it out what that Gotcha is, and I will describe that idea also. You have a machine, and by the way, Ansible also runs with Windows these days, so there's no issue there, apparently. I never tried it, but I think it works with Windows. The Gotcha that I'm talking about is that Ansible is going to work without installation, that without install, the Gotcha here is it will assume that you have SSH. That assumption is a valid assumption. Most, I mean absolutely every 100% of cloud machines have SSH already working, so it's a good assumption to make. The second assumption is that you have Python 2. That's a tricky assumption. Not every machine will have Python. That's a trick that you have to understand that you have to have. That's a requirement. You cannot just assume that it will work. Ansible will just work without having to install anything, because it will assume that you have Python 2 and some machines have Python 3 and don't have 2. That's going to be a problem. That's another problem area to pay attention to. Having said Ansible is a whole lot simpler compared to Chef, easier to use compared to Chef and that's what I will now describe to you. A scenario will be something like this person, this is you, and you have a laptop or desktop and you want to just establish a SSH connection to this machine and here you get to configure whatever you want. You run a playbook on the target machine and it will create what you desire. You write down your desire and it will be implemented here in that location. In the destination, whatever you run the playbook, that will make things happen in that box and it will become what you want it to become. Your desire will be fulfilled. Also the other characteristic, which is idempotence, idempotence is the key characteristic also applicable to Ansible. Meaning if you run the playbook one time and run it again and again and again, any number of times, you still have the final result according to what you desire. It doesn't change the outcome. The outcome stays what you desire, any number of times you run the playbook, no problem. That's the underlying idea. It is very, very similar to Chef and other tools except subtle differences like doesn't require an installation and it doesn't run by itself unless you ask it to run by a cron jobs. All those characteristics are similar. Let's get to an example to play with this other tool. As we already know, it doesn't require any installation, but that is what I will now walk through an exercise to see how it actually works out. I will open this same exercise in this. Yeah, I think we have it ready. What I want to do now is find my exercise. Where is that exercise? No, this is not the exercise. I think it should be on GitHub. I don't think this has exercises in this, maybe it's... Yeah, I think this exercise starts here. We need to have a machine running in the cloud, so we need to create a machine for Ansible in the cloud. We'll go to our creator droplet step and create a droplet like 16.04, choose a $20 droplet in San Francisco, select our key pair and say here I play with Ansible, so Ansible example and create. The machine gets created. It's a fresh new machine and what I like to do is go forward and make sure that the machine has Python. We'll check that. We cannot assume that the machine does or does not have Python. We have to go and actually check. This machine that gets ready here, this machine called Ansible, let's go check whether it has Python. We go here and say, hello, do you have Python? The machine is getting ready for SSH, so SSH is getting started. That's why it is not ready yet, but it should, come on, connect and now it connects. Now here we check, do you have Python and especially Python 2. Come on, Python version. What do we have? Boo, it doesn't have Python. That's the issue that you will occasionally run into and I deliberately chose this version of image which doesn't have Python. I could have chosen another operating system that includes Python, but this one doesn't. So what do we do? You have two choices. You can install Python 3 or install Python Minimal. I think Python Minimal is a better choice because it actually gets us Python 2. You can, of course, go with Python 3, but I want to get to Python 2, which is what Ansible requires. So pseudo, pseudo is not necessary. So apt install and then dash y. It will install Python 2. So it is installing right now. That's the installation which is necessary. You cannot just assume that Python exists. Not every machine will have Python. Most do, but some don't. So that was an example when you don't have it. Having seen that Python is coming and so we go forward and we'll now have to tell that my machine, this machine, is going to be the target for my Ansible play. So now I have, in that machine, I have Ansible, sorry, I have Python, Python dash B, I have it, version 2.7. Good. I come out of that machine, back out, back in my local machine. Now what I want to do now in this local computer is to actually interface with that remote computer using Ansible. So what I'm going to do now is create a folder called testing Ansible and go inside it. And there I have nothing. So I will now create a file. This file contains all the machines that I want to manage using Ansible. Currently only one. And that is where I will now create a file to store the files. This file will store all the machines that I want to manage using Ansible. That file currently doesn't exist, but it will be called hosts. And that is an empty file. I will like to fill it up. Fill it up with what, with this. And what does this say? You need to provide the IP address of the machine you want to manage. That IP address is here. So we'll copy it and dump it right there. So now I know that that's the machine I want to actually manage. And so what I will do is put them in one single line like that. And in that, in that file, I have now multiple entries, actually one entry with three things. The entry I have is a name and Ansible host with an IP address and Ansible user as root. Because I know I can connect to this machine using root login. That's what this cloud provides root access. So we have to use the root login. Other clouds we'll have here and other. And then we have to provide an IP address for that. And a root can be, user username can be different, can be Ubuntu, for example, or some other name. Some other username will be appearing in that example context. So that's what I just did is just one entry, but it specifies the IP address and the username. Having seen that, what I would like to now do is to point out to you that what we are really targeting is what the picture tries to demonstrate is that we have in our folder, in our computer, we sit in this folder, we have a host file that maps to that box, that one. We can manage a bunch of these boxes, all these boxes, but I'm looking at just that box here. And that is the box that I have here. And that's what this test server is. And so that's the one server I'm currently focusing on in my hosts file, targeting this one box right now to begin with. I can add multiple boxes, but not right now. And then I will define my playbook and add this playbook file in here, right next to the host file. And that will contain my playbook. Playbook is executable documentation. You write down what you want in just like documentation format, specifically YAML format. And you know YAML is simple, but YAML can be tricky with indentation. So just pay attention to indentation. It's all YAML. Ansible is full of YAML. And it is sensitive to indentation with white spaces and space and tabs and all that. Same is true with Python, extremely sensitive to tabs and indentations if you're not used to Python. Just get ready for indentation calculations. So make sure your spaces and tabs are properly accounted for. And that's playbook that you write in a YAML file that you will store some data, which is what you write, what you intend. The documentation needs to be written down and you execute that documentation. That's the underlying concept. Now we'll actually run this. We'll put a playbook in there and play with it. So first thing, what I want to do now is to cross check. Let me just quickly read this here. Yeah. So since let's go begin with another step. So here what I want to do is this file, as you know already. This file contains a bunch of hosts that I know and trust, but I want to make it empty because I don't want to trust anything unless I actually want to, because this can contain old information. These are old addresses and old entries that I have attempted to connect to in the past. So this is kind of stale. So I want to get rid of it. Just want you to know that I'm going to delete that file. Because that file is potentially stale entries of hosts that I actually do not know anymore because I may have destroyed them. And so that's why this file is deleted. So we don't have it anymore. So what I want to do now is to, let me read ahead. What I want to do now is to scan the keys. So this key, IP address that we have, I can of course attempt to connect to that box like this and it is going to scan the key and say, are you sure you want to connect to this ECDSA fingerprint is that. And so it is trying to scan the key and I know this machine I created, so I can say yes to it and I can say yes. And when I do that, it connects. And then I have this file, which is what I just deleted and it got created again. So that gets created because you scan the fingerprint. And if you don't want to say yes and no every time you want on a bunch of machines, you have like 1000 machines you create and you don't want to go saying yes, yes, yes, yes to a thousand machines. So you want to scan this ahead of time on your own and create your known host configuration with this file containing all the hosts that you know and trust. Imagine you have a thousand droplets here. I just have one, but imagine if you have a thousand or maybe more, you don't want to be saying yes and yes, thousand times, it will be pathetically boring. So what do you want to do is to go ahead and scan the keys and dump it in that file. That's what I will now demonstrate to you. How do you accomplish that? And so to demonstrate that successfully, I need to again delete this file because it is now populated with some content. So I'll delete that file one more time like this. So now we don't have it. Having done this, what I will now do is to scan the IP address of the machine that we want to connect to ahead of time. So here is the IP address I want to scan. And then once I finish the scan, I want to dump the output in this file that I don't have anymore because I deleted it. And what this will do is pre-populate the known hosts that I have. And now you can see the known host file contains entries corresponding to the IP address that I scanned already. And I can scan these IP addresses ahead of time if I'm doing it in a large number and put those entries redirected to the known host configuration file. And now I have the known host file containing these entries, one and two. Now that I have the entries, I can just connect to SSH and it will just shut up and connect. No problem. No question. No yes or no prompts. And that's the idea is that you want to go do this SSH scan ahead of time if you're dealing with a large number of machines. Just run a script with all the IP addresses you've got and then it will gather all the key fingerprints, dump them in a known host file for you like this. And then your users, when they connect, will not be bothered to answer the yes and no question. It will just shut up and connect. Just like I saw that happening this time. It did not ask me. You can see this again one more time. You can just delete the known host, try to connect. It will say yes or no. But I don't want to say, let's say yes. So I say yes and I quit. And then I see my known host file and it has the entry and so I'll delete it again. And then I'll key scan this time. Key scan and then I connect again and it just connects. That's the idea. You can do this like a repeated basis on a large number of machines if you like. I hope you got the point. Now that I have that taken care of and my known host file actually knows my host, this one, that IP address. So I can now ping that host with a ansible command ping. This ping is not this ping. So don't confuse that ping with this ping. That's not what I'm talking about. This is the actual ping command. That's not what I'm talking about. Ansible ping is not this ping. Having said, I'm going to now run an ansible ping. And when you ping, when you ansible ping a machine, which I am, I'm going to do now, what it will do is respond back with a pong. So ping respond is pong, like that here, it's a success. You say ping, the machine says pong. That's a ping pong scenario using ansible. So what we just saw is the ansible way of pinging a host, a target machine. This target machine. The answer was pong. It did not make a change in the machine state. This machine is still the same as it was to begin with. The state did not change. It just pinged and it got the answer, pong. This succeeded because we know the host. We have that key scan done and we have the key sitting in the known host file. We can remove it and try the ansible ping and see what happens. It prompts you for a yes or no again. And that's boring. So I'll say yes. And then after that, the ping pong succeeds. But I don't want to keep saying this yes for every single box that I might have. So that's the ping pong scenario. In talking in terms of ansible way of describing what I just did, the way you would read this command is to say that I am using the ping module using the inventory of machines that I have stored in the hosts file. So I have a thousand machines listed here, like one and like two and like thousand and like that. A bunch of machines, that is my inventory of machines, the dash I option is the inventory of machines that I want to deal with. Dash M option is the module that I want to run using ansible. So this ping is not this ping, but it is a ansible module called ping. And I'm going to run ansible module ping on this machine from the inventory stored in a file called hosts. That's how you read the command. Now the idea that I just described is the idea of ansible inventory. And this idea is right here. And what you do is you basically store a bunch of files, sorry, a bunch of machines in a file, call it the hosts, like this is one, it contains one machine, you can have many, you can write this same thing in YAML format like this. And I'll show you some YAML examples also in our exercise. But the point here is that this is your host inventory of all the machines you are managing working with inventory in ansible. That's one idea. The second idea is ansible module ping. And so here is the ansible documentation for the ping module that we just ran here. And so what we did is ping module documentation is what we are looking at. And by the way, this site, which is the ansible documentation site, is one of the best written documentations that I have ever seen, very, very nicely written documentation. What it does give you is a whole list of various modules written already for our use. So most of the work is already done by ansible developers, all we need to do is to just identify the correct module and use it. So the way I would go look for is ansible modules. And so here is a list of all the modules you have in ansible. And all the modules listed, there are I think about 300 to 400 modules, never counted it, but it's a large list, maybe it's grown, maybe it's a bigger number. So a large number of modules readily available for almost every cloud, for every action you want to think of, ready-made modules. They work, they are part of ansible, they're built into ansible product, and you can just make use of it. Having said that, that's the idea of using a ready-made module. And we can use ansible without having to write a playbook like I just did. I did not write a playbook yet. I'm just ad hoc using the ping module on this server. And it responds without even having to write a playbook. This method of using ansible is called ad hoc usage. We'll go next. Now what I want to do is to simplify our ansible environment. We have just one file containing the inventory. And so what I will now do is to invest in creating one more file here. And that file will be called ansible configuration. That contains nothing right now, so I'll fill it up like that. What we now have is some description that describes what our ansible configuration is going to look like. So we have a file called hosts that sits here. And that file will be the file that contains our inventory. And it is going to be the inventory file here. You can call it whatever you like. That name is irrelevant. You can call it xyz, but this is what defines that that's where you are storing your inventory. Host file, it contains a list of all the hosts that you know and you want to use with ansible with. And so that's the host file definition, host file. Then you can define the remote user root. In our example, we had this root user defined here. Or you can simplify and cut this out and put that in the configuration so that you don't have to type it every time by just calling it out. Remote user is root. You can also further specify that my private key file is stored in that location and that I don't want to bother with host key checking every single time I known host file checking so I can disable that. This is good for testing, but not for production. So this one is good for testing only. In production, you should keep it true for production because you want to actually check the host that people are connecting in your company. So that should be true in production. For right now, I'm going to leave it as false, but I think you already understand what I'm talking about. Host key check. This check is done through known hosts file, known hosts that we already saw. We play with it a bit already. This is our Ansible configuration in its minimal form, very, very small, very tiny for right now. That's the configuration. This is the host file entry. Having seen this, I will now simplify our host file configuration and we don't have to have this root reference anymore because we took that in our CFG file here. We don't have to have this root called out. So I deleted that from here because you don't have to worry about it. You can just go with the IP address reference to the name and we save the configuration, save the host files, and then go back here and run our ping pong again. It will still work because it knows the root username through configuration. See that? Configuration knows the root username even though we don't have it in the inventory. It doesn't matter. Next, what I want to do is now run arbitrary commands on that box. So we have that box here, that one, and we want to run some arbitrary things there. So for example, I want to see how long it has been running up and running without even visiting the box. I can do remote execution. That's the whole point of this Ansible. It lets you remote execute simply going like this. Show me the uptime on that box. It just gives you the uptime. It tells you that it has been up and running for 21 minutes, right there. Did you log in? Did you go to SSH on that box? No, we didn't bother. Ansible does it for us. Ansible runs primarily on SSH. And in case of Windows, I think it does with BinRM. So if you know what BinRM is, you probably understand what that thing is. But if you don't, there is a lesson, but I'm not going to cover it, but I think it's written down here somewhere, BinRM. Hold on. Where is BinRM? Yeah, there is a BinRM exercise. You can play with it if you like, here. So play with BinRM if you're interested in Windows and all that. So that's the exercise for you. It is written here, but I'm not running it. Having said, let's go back to Ansible. Ansible runs primarily with SSH. As opposed to Windows, it does with BinRM, but SSH, because I don't care about Windows. And so that's the expectation. That's how you have it. This is you running Ansible, and it goes to connect with any number of machines you have over SSH. It expects that you have Python running in these boxes, and machine, machine, machine. All these boxes will expect Python to be available, specifically Python 2. That is the expectation. If you don't have Python 2, it works with 3 also these days. So you do some special changes in the way you interact, and you have to define that I am running Ansible with Python 3, and it will still work, but you just have to be careful about certain things. I'll describe what that thing would be. But apart from that, nothing else is needed for it to run. You just saw that I just ran this uptime command in an ad-hoc action using the command module on this machine using Ansible. So this is a module, this is the command that I want to run, which is uptime, calculate the uptime. So it tells me 21 minutes. I ran this through Ansible without actually manually running SSH. I did not run myself SSH connection. I did not run it myself. I used Ansible to interface with, and you can this way gather uptime for all your boxes like in one shot, say, give me uptime for 1,000 boxes, and it can just give you a summary. That's the idea that you would go and use this scenario in ad-hoc fashion if you like. Let's see some more. For example, you want to check the logs on the boxes that you have. So you just go like this, it gives you the logs. It cannot open, no such file exists because that is not where the log is stored. Maybe the log is stored in here. And that should prompt some log. Apparently those files don't exist. And so let's see if we can get, let's see if there is a file like that. So ls-l var log, let's see what pops up. Yeah, there are files. So we can go check this log, dpkg log or fsgk log or any syslog, you can check these logs right here. And so we can modify this and say, hey, can you get me the syslog, it will give you the syslog tail. I have to go full path, var log syslog. And please, so here is the log coming back from syslog on that machine using the ad-hoc command tail, var log syslog. Now this dmsg does not apply to the machine that I'm dealing with. So I changed my command a little bit to get to another log. Apparently in this machine, there is no dmsg, no big deal. So it's just a different OS. This one is for a different OS and this is what I used. The different operating system, this machine doesn't handle the logs in dmsg, other machines do. This one doesn't. It deals with syslog. Fine. So you have the log. The log begins here, ends here. That's the tail or the log. You can examine the logs on a remote machine without actually visiting them ad-hoc. Go and get me this. So it gets it for you, so syslog example. That's the output that you see in this example. I'll go forward. So these are simple things to just understanding the concept. What you can also do is some interesting things, for example, like this. You want to say, update the apt-cache on all the boxes I have. So here, it'll go and update the apt-cache for Apache 2 and respond back with the result on the target machine that we have, test server, and you will see some response coming back soon. What we are really doing is running the apt module and passing the ad-hoc command, and that's what's happening on the target machine, and you will see some output coming up soon. But the scenario that we'll put this to use is something that is immensely popular and very powerful. The example that I would like to use is called Heartbleed. If you know what Heartbleed is or was, you probably know this thing, or you may have heard of it. So this action finished, and it came back with some response that you can see here. It's a fairly long response, and there is a change happening in the state of the machine. So that's why the color is not green color, but it's a yellow color indicating a change happened. That's this indication of success from a change of the update-cache action that we did using apt-module on that box. So that's the result that you see, that it ran and it finished the action and responded back success. Now, I'll talk about where you can put these ad hoc actions into practical use. So this what you're looking at. If you know Heartbleed, please tell me that you heard of it. Did you? Any of you? So Heartbleed was a bug in open source SSL, and that just came out of the blue because people did not know. And now, it became known on this date when it was published. Some people before that did not know, but as soon as it was published, along with it also came the update to fix the bug. So the bug was in open SSL. This is a library, I think it was 1.01g if I remember right. That version had a bug, and 1.01h was resolved, fixed in this library. And this is such a popular library, it is the open SSL library, that's how machines communicate with each other, SSH, open SSL. Your router uses this. Every Linux machine connects to every other Linux machine uses this, and it had this bug. That's why the the bug is called Heartbleed, because it actually brought down the IRS of Canada. I think it's called, I don't know what they call it in Canada, but the internal something something. And they have this thing called SSN, like we have social security, they have something similar called tax ID number, I don't know what they call it. SIN number, something like that, SIN number. So their SIN numbers got hacked from the, I think it's called Revenue Canada. That was the name of the agency, not IRS, and not social security, but social insurance numbers, SIN numbers in Revenue Canada. So this bug was in their websites also. And a teenager who reviewed this CVE found the bug, noted that Revenue Canada uses this buggy version. He was able to hack Revenue Canada and was able to gather SIN numbers of a whole host of Canadians. You can read this news by the way. And Revenue Canada could not fix, they knew the fix is available, they could not just implement the fix quickly enough before the teenager got in and hacked their entire website and got hold of the social insurance numbers. Now imagine if they had something like Ansible in place, what they could have done, something like this. If they had Ansible, they could have just used a module ad hoc and say, where is that? Command line please, command line coming up. They could have just said something like, hold on, let me create the command. Yeah, that should do it. So the one action is this, just update the app cache on all the machines they have in their infrastructure, thousand machines. And the next action is this, done. And you are taken care of, you are protected already by these two simple steps. You can do this on like hundreds of thousands of machines concurrently. That's the beauty. So if you have a large infrastructure and you have such tools in place and you have an Ansible infrastructure in place, you can just ad hoc run something to patch your entire fleet. And that's what's happening right now, it is updating the app cache, which we did here. And now it's going to upgrade the software that is necessary and it succeeded. And so we have a green color action back response, which tells you that it has succeeded. So it is now running the latest version of all the libraries and binaries that are necessary to run Ubuntu OS. It successfully updated that machine. You can do the same exercise repeatedly in a concurrent fashion, simply by running the same step on all other boxes. So this box, that box, another box you might have. So it doesn't matter. You just add your boxes and just save them. And you have to assign a proper IP address for those boxes, which is like a one-time creation step action. And this box and that box and other box and whatever boxes you have, they will all be immediately patched and your teenager that is trying to hack you will fail. Of course, the IP address will be different for every box. And so you just have to do that one-time action, but that is the idea under the hood. So this idea that you have, the IP addresses could be different like this, or I'm not making up IP addresses right now, but just saying. So if that's the collection of IP addresses you have, you run these two commands like I just did one. Before that, there's update and then upgrade. You are taken care of immediately. Even if you have a calamity like situation, which is what Heartbleed was here with Heartbleed. Heartbleed, oh, did I close the browser? Apparently so. I think I closed out all browsers. Looks like it. No, here's Heartbleed. So this Heartbleed happened a while ago. I think it was like two, three years ago, maybe more. And the fix was simple, just run the update. But then most companies are not equipped to run it like this. They don't have their infrastructure in their control. And that's the point of keeping your things in control so that you can run whatever you want whenever you feel like, run arbitrary commands on the remote machines whenever there is a need for it. You don't run arbitrarily for the sake of doing something arbitrary, but only when you absolutely need to that you have the ability to run it like that. That's the point. That was the arbitrary actions in this example that I just showed you. You can do whatever you feel like, basically whatever you feel like, you can run. Now comes the exercise which is actually going to be using a playbook. So let's see if we can get to the exercise itself. So here is the exercise link. So there is a Git repository for that. So here it opens up. I will also dump this in Git repository in Slack chat so you have access to it. And here is the link. And please clone it in your virtual machine so that we can play with it. So here I'm going to come out of that box, the remote box, and come out of this exercise that I was doing and I'll create a new folder through a Git clone action. So there's a comment here in chat says, I must leave the meeting to go another one. I have to catch up with the video tomorrow. That's okay. I'll enjoy the other meeting and I'll continue with our first run of Ansible in a Docker, sorry, not Docker, Ansible first run inside our VM. So the VM is here. And what I want to do now is clone. So how do you clone? You say, Git clone. And clone it. So that's the link that I'm cloning. This brings up a folder containing a set of exercises for us to play with Ansible. So I will now go to that location called Ansible first run. And in that folder, we have a bunch of files. I'll open it up in Atom and see what do we have. It's opening right now. And here are the files that we have. In this folder, there are certain things that are not strictly necessary. So I would like to cut down a couple of things that are kind of not relevant to the exercise at hand. I'm doing that right now. So that we get to a minimal scenario where we adjust the bare minimum things that we need to have. And that is what I would like to keep. Is that file useful? No. Is this file useful? Yes. So that's the minimal set that I want to keep. And what I want to do here is to run the Ansible first run exercise. This is very similar to a Chef first run exercise, except there are a little bit different structure to this exercise. In this exercise, what do we have is, yeah. So I'm quickly reviewing what I have here. So I can talk about it, Ansible, Apache, Ascamel, okay, yeah. So this example is very similar to this first time Chef exercise that we did in our local machine. This is also going to do the exercise right in the VM, which means this machine that we have in our DigitalOcean droplet, it can go. We don't need it. Right now, we don't need it. So let's see if we can get to that DO droplet and kill it. So killing it right now. And that droplet, the killing action is, I think, more of the point I want to make, is that you should destroy when you're done doing with the machine, otherwise you forget. So I just destroyed that machine. Having said, this exercise runs locally, pretty similar to what we did with the first time Chef exercise. Same idea, which means it will do the same thing that you would do in a Chef scenario is to convert this machine into a Apache web server. Right now, unable to connect because we don't have anything running in our machine here. We don't have Apache 2 running, and we don't have Nginx running, and don't have any Docker containers running. That's why nothing is showing up. Having said that and seen that, I would like to now discuss the exercise itself and make this machine, this VM, into a Apache web server. That's the scenario in this example. So what I would like to do now is just, there's one more cleanup step here. So let me just finish that cleanup step that will cut down any unnecessary files we may not need. And that is what I'm cutting down right now. So here, hold on, did I copy properly? Apparently not. So copy and paste to clean up. There we go. Now we cleaned up nicely. So these are the files that are necessary for the exercise. Very, very small set of files. You can see them in our atom editor also. Now let's go examine what do we contain in these files. So the first thing you notice is that what we want to actually do is to run just one command. That's the command we want to run. And we want to run in a step-by-step fashion to understand how do we run the playbook. By the way, this is a playbook. It asks for super user permissions. So you need to provide our password here. And we run it in a step-by-step fashion. So this playbook that we have here is actually this file. It has hosts, meaning all the machines that this playbook will play against is the list of machines that we will target. And that list contains just this machine, one box. At least for now, it contains that one box. This configuration is not actually configuration, it's about gitignore. So we can ignore this one for right now, these two files. You have to pay attention to the Ansible configuration as to what it means. The playbook here that we have, we have a host entry and a virtual host configuration. So those are the things that we will pay attention to. This how to run file is the action that we have to take, which we are just doing right now. Having seen this, I will now read all the other files that we have here. So the first file we're looking at is Ansible configuration. What this describes us is that the host file where I store my inventory is this file called hosts. And then deprecation warnings, I'm disabling that because it unnecessarily clutters the output that it creates. So I want to just suppress them just to reduce confusion. There's no other reason to suppress it. But I want to suppress unnecessary things to focus on only the thing that mean right now, that matter to us right now. That's the Ansible configuration, which basically describes where is what, like inventory is here and that's it for now. Next, the other file is Apache YAML. This is the playbook and we'll go through great depth in reading this. So we'll visit that later. The next file is hosts. This contains the inventory that we want to run against. So right now in this inventory, we have two entries. One of them is the local host machine, meaning this machine itself. And in this example, what I seem to have is two entries. And those two entries are, let's go see them. So adjusting a little bit here and seeing the entries. And so here are the two entries. So let's go break this line into multiple parts. The second entry is a machine called test. The first entry is this machine itself, local host. And the connection to this machine doesn't require SSH. So the connection is actually local connection, don't require SSH. I am on the machine already right here. So no need to SSH. I can just run it locally. The second machine that I have in this list called test. It is a machine which needs to be connected via SSH. And this is the IP address, which is actually wrong to get a new machine and new IP address and put that entry here. That is just a dummy example. It needs to be connected with the username. So that username we have to have is either root or if we decide to change the username, then we have to change the root name to some other name. So it depends on where you want to get the machine from. Next, the private keys stored in that file, which we already know. That's where we store our private keys, the IDRSA file. That's where the private keys go in our example. So with this idea, we can run this same exercise in two different places. One in this machine itself. And second, we can go to Digital Ocean and grab one more box, put the IP address right here and get it to work on that box also. I think that's a good idea to do it. So I'll just quickly create one more box in another cloud, which is this one again. And we log in and then we have a box and that's the box. And so we grab it and we'll say, give me 16.04 and give me a cheap box and then put that in San Francisco and use my key pair and call it this name test, just using the name test. And then create. The box gets created. I get an IP address for this machine. The IP address is that one. So I copy it, put it right here, paste, save. I know the username for this machine is root. I can just keep the root username. I also know that this private key needs to change. It is not that name, but ID underscore RSA. And here, what I'm going to do now is that this is how you interface with the Python 3 reference. So if you have to have a machine that runs Python 3 and not Python 2, you have to call it out like that. That's a way to tell Ansible that I intend to use Python 3. When it talks to this box, I need to use Python 3. And that's how you tell Ansible that when I'm talking to this box, please speak Python version 3. When I'm talking to this box, just use the default local connection. Don't even bother about SSH. And the box has Python 2. So don't have to call it out. Now we have to check whether the box there actually has Python 3 on this IP address. Let us check. Does it have Python 3 there already? Let's go find out. So here we go, SSH root at IP address and see whether it has Python 3 already, Python version. And there is no Python 3 there. So what do we do? We install Python 3. How do you install, apt install Python 3. And it does. Apparently it's already installed. Oh yeah, we already had it. So what we need to do is just say Python 3 dash B and that should run. There it is. So we have Python 3. We don't even have to install it. Nice. The check was not this, but this, that's the check for Python 3. So don't have to do anything. So they come out. Now we are able to connect to two different boxes and run our playbook. The playbook is this one. So let's go see the playbook. So what I want to do now is to run this play one step at a time. How do you run? Like this. Now we have two machines here and running the same command one step at a time on two machines can be a little bit confusing. So what I will do is hide the second host for right now. I hide it by making a hashtag in front of it so that it doesn't activate. And then I close. And then I run this play step by step. And I'm going to invoke that. And this will run only on the local machine because I have made this line a comment by putting a hash in there. I'm not touching it right now. Just touching local host. Having said, here it goes, command, terminal, and then run Ansible playbook play by play. Which playbook? This one. And run it like this. So I want to put these two windows side by side. And so here it goes. So I have a playbook on one end, on the left side, and the action happening on the right side. What I'm doing is running only on one machine. Just realize that. Only one machine. And then I'm saying run the Apache YAML playbook. Ask me for the super user password. And go step by step. Don't run the whole thing in one shot. Because if I do, the whole thing will work. And then I will have no idea what just happened. So I want to actually learn. So that's why I have this step by step action. I will say, okay, go ahead. So it is asking me for the super user password. I'm going to give it the super user password. And the password is cloud genius. So I proceed. And the first thing it does is step by step. The first task it wants to do is the task of gathering facts. What are we talking about here? What are we dealing with in this host called local host? What do we have already? What's the inventory? Let's gather the facts around the machine itself. And that is a fact gathering action, which is the very first action of any Ansible play unless you disable it. You can say don't gather facts. You can say gather facts, false, something like this. Gather facts. I don't know the exact syntax, but this is the idea. You have to say gather facts, false. It will not gather facts. And you have to pay attention to indentation. Something like that. You have to write it. I don't know the exact syntax, how you write it, but you can Google. But you can disable gathering facts, but I have not disabled it. So by default, it wants to gather facts. So it is asking me for my permission. Do you want me to run this first step? The first step is to gather the facts around the machine that you're dealing with. And I can say yes or no, or continue. If I say yes, it will go and gather. So I'll say yes. And this is a manual step-by-step action just to understand the flow of the playbook. In reality, you will not have this step, step-by-step. It just executes the whole thing in one shot. But for right now, I'm doing it step-by-step so that we understand what's going on. So it'll say yes, and it proceeds forward. And so it says, okay, I gathered the facts around this machine called localhost. And you will notice that it doesn't touch this other machine that we have here. The other machine that we have is the test machine. We are not touching it because we have commented it. So we are dealing with only the localhost machine. So it gathered facts, localhost. And it knows about the machine and its characteristics and the operating system and all the details around it. Nice. Next task is install packages task. This package, this is the action. So now you can see that I am describing this task list in terms of things to do. First task, gather facts, which is a default task. You don't have to describe it. You can disable it, but don't have to call it out. It just does by default. The first actual task that you write is this, what you write here, is this block, which is what describes your first task. Then we have another block that describes the second task. Then another block that describes the next task. And like that, you have a list of tasks in the playbook. That's how you write a playbook. It's very simple to understand and very simple to write and very simple to use Ansible modules inside a task. Like here is the apt module. Here is the service module. Here is the Apache 2 module, here is the line in file module. We'll go pay attention to what these things mean as we go along each and every step. But for right now, the idea here is look at the task getting executed step by step. And the next task being executed is the action to install packages. But with packages, well, it describes the name of the packages are listed in the variable called item. And you fill it up with items, Apache 2 and git. So I want to have two packages installed. You can have more packages like this if you like. And you can just name the package. So name that, sorry, the other package. What am I typing, other package? Just name whatever you like. Other package name can be edge top, whatever packages you can just list that to this. So you list up all the packages that you want to have installed. You can just list them in an array with items array. This is the YAML representation of an array. So git is one item, Apache 2 is another item. These two items will be installed with the apt module. And before it installs, it will update the apt cache to the latest state. That's how you succinctly describe what you want to install. And it will install it for you. So as soon as I say yes, it will install Apache, it will install git, and then ask me for the next step. So let's go say yes, here I say yes. And it is installing it. And then the installation finishes for those two steps, and then we go to the next step. So right now it is installing Apache and git. And when this finished, you can see the yellow color change. This yellow indicates change happens. This action of gathering facts did not change the state of the machine. It is still green color. Nothing changed. Here things changed. You actually installed Apache and installed git. That was a change. So it shows you in yellow color, change, green color, no change, and red color, failure. You will see red also eventually. Right now, we have made sure that we are able to change the state of the machine by installing two packages with the first action or the second action, this action. Next, if you say yes to this, it will take this action, which is this action. And the action here is to enable Apache. And what we're really doing is to start the service. So service state will be started. Right now, it is not, or maybe it is. We'll find out what it is and the current state is and whether there is a change or not by looking at the green color or yellow color for this action. So we'll say yes. And it's probably green color because the state already is started. As soon as you install Apache, Apache itself should start by itself. But if that's not the case, this will start it. So we'll say if it is yellow color, then the state was not started. And if it is green color, it was already started. So with that understood, I will say yes and see what happens. I think it is green. Let's go cheap. It is green. So the green color indicates that the action to enable Apache was not really something that it did because there was no change in the state because it was already enabled. And so this action turns out to be green color because Apache automatically, when it installs, will also enable Apache so that this action was not actually necessary to change the state of the machine. So it did nothing. Next action is to enable the mod rewrite module and that is this action. Now this action involves using a Apache module. And again, the way I say this is the name of the module is Apache to module. And what this does is to allow Apache to install a module called mod rewrite. And that's the module that you will see it will install and make sure that such a module called mod rewrite is actually present in the box. And when you do such a thing, you need to also restart Apache. And so instead of restarting Apache right away, what it does, it notifies a handler to restart the Apache later on. And we have a handler at the bottom. You can see that there is a handler defined. And what this handler does is that for this restart and this restart and this restart, it will just collect all the restart requests and restart only one time. That's what this purpose of this handler is. So it will collect requests for restart, restart, restart, and restart. You don't have to restart it four different times. You just collect all the requests and at the end, just restart Apache once. That's the idea. So for this action, the restart will not happen right away. But you will see that this action to make sure, and this is how you read the language is very particular in this, the way I'm describing you, listen to this. The way you describe this is that you have to make sure that the module, Apache 2 module is present on the machine. It doesn't tell you how to install it. It is declarative. It declares that I need to make sure that the module called Apache 2 is, sorry, the module called rewrite, mod rewrite is present. How you install it, I don't care. That's Ansible's problem. All I want is to make sure that the rewrite module is present by using the Apache 2 module, and that is this action. So I'll say yes to it. What this will do is basically ensure that the rewrite module is present on the machine. So we'll say yes. And so apparently the rewrite module was not present. So it made sure that it is present, enabled mod rewrite. So that action shows yellow. That means this module was not enabled to begin with. So we enabled it. Thank you Ansible. But you know what? It did not restart Apache. But that is okay. Sorry, it did not restart Apache and that is okay because we have a handler to do that at the end. So we'll do that at that end, at the end point. Don't have to restart it multiple times. Next comes one of the most interesting modules in Ansible. And that module is called line in file. I think it is one of the most interesting modules in Ansible and I'll tell you why. Let's read it. Let's read about what is line in file. So here line in file and here it is. So what this does is lets you manage lines in text files. What's the big idea here again? The idea is that you can manipulate text files by managing lines in the file. It lets you edit the file using Ansible and I'll give you some examples. Managing files using Ansible in a systematic, programmatic way is actually very powerful. Let's see some examples here. And so examples. And here is an example. Suppose you want to change some file called, let me make it a bigger, a little bit bigger. Yeah. Suppose you want to edit this file in the machine and look for a line that begins with these words and make it look like this. So you will find in most UNIX configurations, there will be a file like that to ensure security enhanced Linux feature set. And the file will contain words like this, se Linux equal and will be empty after that. That's the line in this file. This file will have a line like that and it will be empty. And we want to make sure that we fill it up with the word enforcing. And by the way, we want to do that on hundreds of thousands of machines in multiple locations spread out on the internet on some cloud or multiple clouds, including one machine in your garage, if you like, or your grandmother's laptop, it doesn't matter what machines. Some machines somewhere and you want to enforce se Linux on all those machines without having to do this like a hundred thousand times manually. You can do this manually, but it gets pretty boring. Edit this file and add this word enforcing every single computer. Oh my God, who's going to do that? And that's where this thing comes in handy. What you would do is you'll say line in file, path, that file, look for a regular expression that begins with the words se Linux equal sign and make it look like this, done. And run the play. It'll make it happen on hundreds of thousands of machines, no problem. Again, another one. The file called etsy-sudoers. If you want to make sure there is no such entry in that file, no such entry, no entry that contains the words begins with the word percent wheel, you want to remove the group membership wheel from the sudoers group. This line, wherever it has in that file, make sure that there is no such entry. So delete everything. You want to delete that regular expression, make sure that the state is absent. If you have such a thing begins with a percent wheel, delete it. It'll go look at that file, this file, and clean it up. Clean it up with those regular expressions and delete those specific lines. Another example, in the etsy-host file, you look for the regular expression 127.001. And if you find, make it look like this line and change the root and group ownerships to this 0644 pattern. So the root and user permissions are set in that location. So that's what you will see the line in file module will go look at that file, look for this regular expression, and append the words local host in that line that begins with 127.001. More examples. This configuration file, look for the word listen, beginning with listen. And so you will have a file called httpdconf, this file. It will have a word called listen and nothing after that. And so you want to fill it up. So it begins with the line here, begins with the word listen. So that's what this regular expression says is with a carrot. This carrot, by the way, as you know, this carrot, this guy is the word that shows beginning with listen. So any line that begins with the word listen, if it is empty, fill it up with port number 8080 so that we know our Apache thing, httpdconf, will listen for port number 8080. That's how you make a change happen using this segment. And you can do this across multiple machines that you might have in your fleet of inventory. Same ideas apply. So that's the concept. It is a super powerful method of managing a large number of fleets, doing all the dirty work that is necessary to make things happen exactly the way you want. Line in file. I think it's one of the best modules in Ansible. Having said this, let's go produce an action. So here is your line in file. Let's see what we want to do. What we want to do is to go listen for this file. Let's see Apache to portsconf. And so what I'll do is I'll just illustrate this idea in a new, oops, I just said no, no by accident. I accidentally said no. I should have actually opened a new terminal. That's what I wanted. And instead of that, I pressed N for no reason. So I will break that exercise and do it again. It's no big deal. Do it again. So cloud genius and say gathering facts, say yes. And then install packages, say yes. There's nothing to do. It will not do anything this time. It will say green because Apache is installed and Git is installed. And then the enable action should also be quick. But the point is that I want to go talk about line in file. So that while that thing is happening, I will go talk about line in file here by looking at cat at C, Apache two, and then ports.conf and get file ports.conf. That configuration file is what is looking like what we have here. So you will see that it does not have listen and then the port number HTTP port. Let's see what we have here. Hold on. Let me just finish this action. So enable Apache two, yes. And then mod rewrite, say yes. And so all these are green actions. Now becomes the action of Apache to listen on port number and then the variable HTTP port. So this variable HTTP port is defined in here. And what does that variable mean? It means eight zero. That's what this variable is. Variables are defined here. So we have to go look for a line called listen space and make it look like listen eight zero. Right now in our file, we have a file called at C ports.conf here and it contains lines like listen with a space and it already has 80. That's not a good demo. So what I want to do is make that something different. It has a listen 80, which is exactly what we want to begin with. But I want to actually manually disturb it a little bit. How do I disturb it? I'll go hack it like that. And type the password and then go make it different, like something like this. This is not 80. This is some other number, right? Let's save it. I just destroyed it. See the destruction there. And I want to make it, programmatically make it eight zero. And that's what line in file will do now. And I say, yes, when I say yes, this will go look at that at C Apache to ports.conf. Look for the regular expression and begin with listen and make that look like listen HTTP port, variable value is 80 and the state of that line in file is present. Make sure that such a line is present in this file. So I'll say yes. And then something changed. What changed? Let's go figure it out. So here we'll again examine our file. And you see that this is now listen 80 again. I did hack. You saw me hacking, made it something weird, different, and it fixed it by itself. And that hack was basically to demonstrate this point. And I think we have crossed over seven o'clock time. So what I would like to do is actually break this exercise and not take up too much of your time. I'll resume this next time. And that's the plan. I did not pay attention. It's already 7.10 or something, 7.8. So I'm stopping recording right now. I'm still here for questions. I will resume this exercise exactly from this point onwards going forward. And we'll understand Ansible, we'll use Ansible to construct a playground for Docker in a systematic fashion and then switch back to Docker again. That's the plan. So with that, I will stop recording. I'm still here.