Hello, David. How are you doing? I'm doing good. Good to see you. Opening up my cameras right now. Okay. Give me a second. So that's pretty funny that somebody deleted a library on GitHub. GitLab. It's a different service, but yeah. Yeah, it is fun, isn't it? Yeah, you see these things happen because of stupidity, primarily. I call this stupidity. Because people are not reading, they don't think they just do things on a production machine, not just machine, but a system, a complete system. They actually suffer through data loss, make people suffer through that, which is pathetic. There is no other way to describe this, honestly. Yes, it is. But I must admit I've done things in my past that have been rather stupid as well. I know. So everybody does mistakes, but I would rather not make mistakes on a production system. Oh, yes. Yeah, that's right. Yeah, I usually try and change my background of my terminal or something to make it very clear. Right. Makes sense. Makes sense. So I think you can see me. Yep. I like the two cameras, by the way. Okay, good. Good to know. Yeah, two cameras are different. I just started doing this from the last session just to give you a different perspective. Yeah, it is, you know, now that I have the capability, I said, why not? So just give you this perspective of me talking to this camera, this camera, and this microphone actually that I use to talk to you guys. Let me adjust and wire this up in a fashion that makes it a clean audio. This is the one that I was mentioning. I think I told you this $670, something like that, silly microphone, expensive, but it is nice. It is, I think, nice. You should tell me whether it is nice or not. I find it useful. Oh, yes. It's very clear when you're wearing it. Right. When I wear it here, that should be really clear sound. It should not have a noise, no echo, no nothing. And that is beautiful that I like about that part. Yep. Okay, let's see if we have more people joining in. I'm going to open up my notepad. And here we go. Thanks for joining us. Yeah. So this is the way we were writing in this screen, I guess. Yes. And here, the last time we were talking about this thing. Okay, good. So I think we are on the right page and adjusting this width a little bit. Yes, there we go. Adjusting the browser, the chat screen, and Slack chat here. I should adjust this also so I can see my Slack chat. And then we should proceed. We have only three people right now, four people now. Good, good, good, good. So here we go. Yes. So four o'clock is still a little early for West Coast people to get out of work. That's why we run into this issue of people trickling in as they come out of work. They join in as they drive. I have seen people drive and at the time that they're driving, they are participating, which is just amazing. And it shows dedication. I mean, nobody would listen to something that you're driving and participating. So we have a small group right now, but I think we should start. So I will begin with our quick recap. We have how many? There are seven people or only four cameras? Okay, the cameras are hiding. I see. You guys are hiding from me. Interesting. So let me adjust my display gallery view. I see now all people. Okay, let us now switch this to full screen, share my desktop and off we go. Here we go. So I am sharing my desktop. You should be able to see my desktop screen, which is 50% browser and the other 50% is like this notepad. And I will open a curtain to hide my unnecessary stuff that I have on my desktop and also open my virtual machine. And then begin discussing as to what we really want to cover today with a focus on a couple of things that I want you to take and take note of. And those things are kind of different and unusual in a sense that I will describe. Give me a second. I'm adjusting one more thing before I start. And that is okay. And this view should go there apparently. Exit full screen, move this one over there like that. Still not happy with my setup today for some reason. But whatever, I'll move on, move on with what we have. Okay, I think I'm good now. Okay, so a couple of things I want you to take away from today's discussion. It is about the questions that we ask about anything that we do is why are we doing things? That is the most important question. This is priority zero, P-R-I zero, the top order priority. Why are we doing things? That is the first thing I want you to take note of. Second thing is what are we doing? I mean, that's obvious as to what are we talking about? And the last item, which is also important, is how do we do that? How to do it? And this piece is trivial. You can find it on Google and you will typically find the answer, most likely. If you don't find an answer, I'll give you the answer. If I don't know the answer, we'll figure it out together. This is not where I want you to focus as to how to do certain things. That is not the idea to learn. The learning actually happens here. Why are we doing certain things in a certain fashion? And the concept behind that thing that we are trying to accomplish. I think that is the most important thing as to why are we doing certain things in a certain fashion? And what are the other ways of doing the same thing? And then comes the core idea about, okay, what are we talking about? And then how to. This is really trivial. And I would rather you not focus your energy too much in that direction because it is trivial. I mean, I just said that. Having said, we want to discuss this exercise that we were doing halfway through. The last time we were doing this exercise, module number 17. And I will basically recap the whole thing, do the whole thing from scratch again. But before I jump into the exercise, I want to talk about the why part. The what part. And then, of course, this. We'll do that live. We'll do that live as we do always. And we'll do this just like on the exercise I was halfway through doing the last time. But before any of this, we will begin focusing on the concept, the core idea. Why are we doing it? How does it help? Who does it help? And how are we involved? And then talk about what and how to. So we are discussing about platform as a service. We are discussing about running our own platform as a service. We are using open source products. Open source such as this example uses this software. This that you know is available on GitHub. Now, why are we doing this? We are doing this primarily to allow our developers, enable our developers in deploying their applications onto this platform. Our own platform. So we will have allow our developers to deploy on the platform, which means we have a platform. And on that platform, developers will come like this is the developer number 1, D1. He brings his application A1 and he deploys it here. This is developer number D2. His application is A2 and he deploys that application here. And they don't need to worry about the underlying complexity, which actually involves some infrastructure as a service under the hood and a bunch of other things that goes along. From a developer's perspective, the idea is create an app and push. This guy creates an app and push. And when they push, it goes live. It needs to go live on the platform and it will take a URL, something like some random string, some random string dot subdomain dot domain dot whatever you have. That's where it, this subdomain is not necessary. It goes straight on the domain, but then I don't want to disturb your domains. So that's why we are choosing a subdomain to not bother with the settings that are responsible for this. You may be running your email, your other services. I don't want to disturb that. So that's why I'm suggesting that we create a subdomain and use that as a placeholder for this some random string. So this random string that I mentioned about, if one application gets deployed, that will be assigned some random string dot your subdomain dot domain. It will get assigned a random name here. You will have another application from this developer D2, this developer D1 deploys application, and it will get another random name dot subdomain dot domain. That is what is likely to happen so that these guys, these developers will be able to access their applications comfortably as soon as they push. They should be able to see the app. To enable that scenario, we need to have a wildcard DNS working. Wildcard so that we can generate random strings and assign it. To enable this scenario, we need to create a completely separate zone file for this subdomain, a separate zone file for this, which requires you to use a separate service. In my example, I'm using Google Cloud DNS. That will host the zone for this. Your original domain may be hosted in another location, such as maybe Cloudflare, like many of you using Cloudflare. The original domain, that zone may be located in another service such as Cloudflare, for example, and that is the zone where your main domain sits. The idea is to carve out a completely separate zone for the subdomain, and that will happen by introducing a name server record entry for this in here. That is what needs to happen. That will enable the wildcard scenario, which will allow random developers in your company to deploy random applications as they feel like, as they desire, and they can just push A3, and it gets deployed. That's what we are really trying to do, is to streamline the work of our team members in our company to make it easy on them to just push and go live, push and go live. The underlying platform will help them go live. That is what we are really building. The reason we build this is because we are trying to help our development team, allowing them to deploy on-demand. It's an on-demand platform as a service. It meets your characteristics that are expected of a cloud service. If you remember and go back to the definition of cloud computing, it has those specific definitions. There are five characteristics. This thing will meet that because we are designing it to be like that. We are designing to use an underlying infrastructure solution on which we are developing a platform as a service, and we are basically enabling our customers. These are our customers, the developers. They develop apps. They will deploy their applications, A1, A2, A3. These guys will get random names assigned on the platform. The platform will have some subdomain name, and that is where it will run these applications. That's the idea that we are doing this to help our developers. That's the core idea. We are doing this in a fashion that meets those five characteristics of cloud computing, which you may remember are five characteristics of cloud computing. You can just figure it out what those are. We'll just go straight to the definition here. The definition is right here. You can see the definition is... You probably know this. I don't need to repeat, but you understand what I'm talking about. Those five characteristics we need to meet, and that's the reason why we are doing it. Now, let us take the example of this domain. The domain I will use in my example will be the Cloud Genius domain. This domain runs a bunch of services already, so I don't want to mess with it. Therefore, I create a subdomain. This domain is managed by Cloudflare. I want this domain to be used by another company. You can use any other company, by the way. I'm just using this. You can use Amazon or just any other company. Even you can use Cloudflare itself. I don't know about Cloudflare will allow that or not, but I think somebody else will allow. Use Google, use Amazon, use other services. That should be okay. When you create this kind of a subdomain, you need to have a name server record here corresponding to this entry in your Cloudflare account that points to the Google DNS zone file. That entry will look something like this. Dig. Hello. Name server, please. Give me the name servers. Here they are. You can see that I have four entries, one, two, three, and four. These are name server entries, NS, and they are in the Cloudflare account, but they are pointing to Google domains. How did I find out these values? What do I write here? I'll ask Google, what do you want me to use? I go to cloud.google.com, and there I go to the console. In Google console, there is a place to create a zone. I create a zone in there. We will find that in this. Let's see where the zone is. Networking, and then Cloud DNS. Here I created a zone called hello. In that zone, it gave me these name server records, these entries. These are the entries that I need to create in Cloudflare. I go to Cloudflare. Excuse me, and log in. When I do, in Cloud Genius domain, the DNS, I look up hello, and I find there are four entries. These are the same that I have that match item by item, line by line. Four of them match what Google wants us to put. This activates the subdomain as a full-fledged place for us to use as a wildcard domain. That is how you do it. Now we will proceed. We will begin at the very top, at this point, so that we will have one video for you to replay if you want, and play the entire exercise when you do this. That is what I intend to do. In my VM here, I will put this on the side, and go begin from step number one here. That is what I intend to do. Here in my computer, I may have other older things. I want to delete all of them. There is this days folder. I want to get rid of. I tried doing this in a free service called Hurricane Electric. Which company? Hurricane Electric Services. What did you try? The zone? I tried to create the subdomain there. It didn't let me. It said it needs a domain. I know. That is why I am suggesting Google or Amazon. Some service providers don't provide the full feature set. That is the problem you will run into occasionally. They have a DNS solution, but just spend 40 cents for one month. Actually, you don't even have to spend for one month. Just a couple of days. I was trying to get because my actual thing is on Google. You can then go to Amazon. Go to Amazon Route 53. Amazon AWS Route 53. Go here. That is also similarly priced. It is 40 cents per domain. No big deal. Give me a second. I think somebody just popped up. I am going to start this meeting one more time. That is me coming online. Now I can see myself again. Here is the video. I am deleting this old location. Basically, getting rid of all the stuff that I have from the previous attempts. Cleaning it up. Gone, gone. Everything is gone. All other things that are related to this particular exercise, I will basically clean them up. I will stick to the beginning point. What we are trying to accomplish is get the source code of this platform from here. Like that. Get the source code. Then check out a particular branch. The branch I want to use is the one that I have tested. I know it works. I tried it yesterday. It works yesterday because I saw it working. I am going to use that exact same branch number, 113. That is what I want to check out. There are lots of branches available, but I would like to use this particular one because I know it works. Here we go. Git checkout. I checked out that particular version. I can check my status to say, git status. I can see that I am on. My head is pointing to 113. Nice. A couple of things I will also examine. Atom. In the Atom Editor, you will find that I have a folder called Contribution, Contrib. In there, there is this folder called Core OS, which by the way is the operating system that I need to have for this exercise in the underlying infrastructure. This operating system called Core OS is actually a pretty beautiful OS. It is Linux and it has a specialty. The specialty is that it does not contain anything that is not needed to run containers. It is strictly focused on containers. That's the only thing it does. One thing, do it well and do exactly that one thing is it is designed to run containers. It is small, tiny. This is what I call Just Enough Operating System, J-E-O-S. This idea of Just Enough Operating System basically means the bare minimum thing that you can get and absolutely nothing else to get something to work. This is the right approach towards building something is to cut the crap. Nice. This is the idea. People call it juice, as you can see in Wikipedia here. It's called juice. You will find computers with both load of software loaded that you don't actually use and it brings the hard disk bigger, slows down the machine. All of that you can get rid of by using Just Enough OS. Always think like this. Think that you don't want to have unnecessary stuff beginning from as small as you can begin mechanically, very methodically add only the elements that you need and absolutely nothing else. That will cut down your risk exposure, your security coverage. You have to worry about your exposure to the world is reduced. You're less exposed to threats. You're doing just that one thing that your application needs and all these other benefits come along. That is what Core OS is just one example of that. There are many other products like that, all based on Linux, by the way. Microsoft also has a thing like that. It is called Server Core. They also now have a thing called Server Core. This is available from Microsoft. It is just the bare minimum Windows Server that basically boots and does the essential things. It doesn't have a display, runs your terminal services, so you can remote desktop with it. In fact, I think it may not even have a desktop. I think remote desktop may not be there. I'm not sure. I haven't tried the latest version of Server Core, but I think they have something like SSH for Windows that works. You can use just the bare minimum minimalistic installation of a machine. This is the Windows version of it. You can see this idea from Core OS. That is the foundation that this particular implementation will use. Currently, in that folder, you have this file called user data example file, which is already there. This is just an example. It needs these variables filled out, discovery URL variable, for example. It has not been filled yet, so we have to generate a URL. That is what we will do next. In the next step, you will find that I am going to create a discovery URL in the subsequent step. I would like to mention that you need to install this binary, day's control binary, which is... I think we installed it last time. The steps are provided right here. When I have done it already, I can just run this command to check whether I have it correctly done. I can see that I have the version 133 already loaded. Nice. I am skipping that step, by the way, here. I am skipping these steps, which is what will get me day's control binary loaded up in the command line that gives me this version. That is what you need to do when you run these steps to follow that to get to this point. Next, I am also skipping this portion, which is going to install the day's binary, not the control, just days here. I have that also installed following these steps here. Now, I need to set up a key pair. This key pair is available in my SSH folder. As you can see, in this folder, I had this idrsa, idrsa.pub from a previous attempt. The other day, when we ran this exercise, I have also generated days and days.pub. Those key pairs, I generated that because I ran this command. It generates that key pair with that name. You basically go like this and enter, and that will generate a key pair. I did not run it because I don't need to because I already have those key pairs. There is no point generating another key pair. I am skipping that step as well. Next, I have generated a fingerprint like this that I can generate pretty much like that. Here we go. This is the fingerprint that I created for my public key, the days.pub file. This file generates this fingerprint key here. I need to make note of that fingerprint. I have saved that fingerprint right here. This is my fingerprint. I have also saved it in here, line number three. I have already prepared it and kept it safe for basically expediting our work today. Otherwise, I would have to take this fingerprint from here and copy it into the temporary placeholder command, which is what I will like to execute when I want to build a bunch of servers as a cluster, which I will be using as the foundation for my platform as a service. You can also see that the same key that I have provided this public key over to my Digital Ocean Cloud in the security settings, you can see that this day's key is available. It matches the fingerprint right here. As you can see, the fingerprint matches. I have also generated a token. The token is available in the API button on top. Here on the upper section, API, generate a token. That is how you generate a token. In response, you will get a long string that looks like this. I have copied that string over to here in line number five. I will be using that command number five through 10. This command, as you already know, we have attempted that the last time. I will do it again this time. I have the token in place. I have the public key fingerprint also in place for this public key. What I need to do is make sure that I don't have any droplets running, which I deleted them all. I want to continue this exercise. I have generated the fingerprint. Make sure that I give the public key over to Digital Ocean in the settings section here, and that public key needs to be copied and pasted into that location. You basically cat the contents of the public key, and you paste the public key into the Digital Ocean interface, and then cross-check the fingerprint that you receive in this command. You cross-check with what you see in here in the day section. You cross-check the fingerprint is actually accurate and matching. When you match that, you are happy about making sure that the fingerprint is correct, that you have the token in place. This is the token, and this is your fingerprint. You keep them in a separate place. You paste the fingerprint like here, and you take your token, and you basically paste the token like here. That's how it constructs the command that we want to run next. You can see that the token looks something like this. One thing that most of you tend to forget, I know a couple of you have tried this exercise, you should not forget to create the discovery URL. What happens when you create that discovery URL is it allows these machines that will generate. What we are doing is on the underlying infrastructure as a service, we are going to create a bunch of machines. You can have more as you like, and these machines will run your platform as a service. These machines will run it as a collection together in form of a cluster. These machines are independent on their own. They need to know that I have a brother and sister there. They need to know that I have my family. They will discover each other through a discovery URL. That happens through a service called ETCD. If you go to the website for ETCD, you will find that it is actually a service available from CoreOS organization, and we will be using this service in constructing a discovery URL for our own use. We want to actually include that discovery URL inside our CoreOS user data. I think I made a mistake. Hold on. No mistake. I need to include that file called user data without the word example. There is this example file available, which has this discovery URL variable empty. I don't have a value there. I need to create a new file using this template in this folder, which contains the correct value generated by a discovery URL. I need to generate a discovery URL, which happens like this. Make discovery URL. I will go back to my virtual machine and actually generate a discovery URL. When I do that, you will see that the CoreOS folder here now contains one more file. I'll run the command, make discovery URL. Let me run it now. Off we go. You can see that a new file has popped up in this location right here. It's called user data. It is pretty much a replica of the file underneath, except this one includes the value of a discovery URL. Let's see where that value is. Here is the discovery URL that we have generated, F6EchoCharlie. The same value you see F6EchoCharlie is what is matching the URL there. That is a critical element that is needed for these nodes that we will create in DigitalOcean so that they will discover each other. That is what we are trying to accomplish. That's what we just did with this command. Next, in our steps, we need to make sure that we are in this folder. That is something that is absolutely critical. I would like to point out on the side note something very important that I think I should and therefore I'm doing it. I think most of you who are new to the command line will appreciate what I'm describing right now. Watch this simply. I'm looking to type a command to examine my folder structure. How is my folder hierarchy? How are my files laid out? That can be done with a simple command called tree. Tree, enter. You see a large tree there, but it's very hard to read. I will simplify that command with a tree dash L and space and number 1. It shows me a tree, but shows me only one level deep. I can step out of this folder and then run the same command tree L 1. I see that all the folder structure in my home directory show up. I can now expand this to say number 2. I can now see that it has gone one step beyond and actually is showing me the tree depth a little bit deeper. I have a lot more stuff in my folder and that's how you look at the tree. It shows you an expanded form. You will see that I can even further modify this command a little bit to say dash L space L and A. This A will include all the files, not just those visible files. I'm expanding this view to show me the entire tree including hidden files. Now I run this and you can see that I have a lot of items here called dot something, dot this, dot terraform, dot watershed, dot this, dot that. All these dot files are hidden. You will also notice up here somewhere that there is a folder called dot SSH, which is what I'm trying to locate. Here, dot SSH is the hidden folder inside which I have the IDRSA, IDRSA.pub, dais, dais.pub, my config file that will allow me to jump through a jump box or an add box if I'm using a VPC scenario, and the known hosts file. These files are all inside a folder which is hidden. Another thing I would like you to point out is this idea of PWD, Present Working Directory. Where am I in the tree? You can tell. I am in the home location. This is my home location. Home location is a specific location for the user. It does not mean this. This is your home. That is not what home means. Home means tilde. Tilde is your home. Home also means, and by the way, here you can see the Public Present Working Directory is home user. This is your home. User home is this. Slash home is the machine home. That is not your home. Your home is home user. Your name is user in this machine. Tilde is the indication of your home location. Tilde is also indicated by the variable dollar home. Now you can check that you are in your home, which happens to be home user. You can go to some random place like this and then say PWD. It will tell you that you are inside that random place. And it is also indicated here in the prompt. You can go back to your home by saying CD tilde, and you will see that the prompt changes. This portion has changed. Only the tilde is left right there. And that is an indicator that you are indeed in your home. And these aspects of very subtly and very carefully examining your current location is critical in typing a command. There are a couple of other things that I want you to remember. Those things I think I mentioned here is those three things. It is to respect others' privacy. Think before you type. And with great power comes great responsibility. You know this. Uncle Ben said that. You know that. So with that understood, there is a case from yesterday called GitLab, which you may have heard of. They destroyed themselves, by the way, accidentally and I think stupidly. But they are running through an accident. They are talking about it. They basically destroyed their customer data. We lost six hours of database data, issues, merge requests, user comments, snippets, blah, blah, blah, all that for GitLab.com, which is silly. It is absolutely silly that somebody is doing this. They basically ran RM-RF on the production database. Stupid, but that's what they did. And so you have data loss on a live production database with a bunch of customers screaming, idiots. But that's what happens when you don't think before you type, especially you're running a production database. Having said, bottom line for you, please read before you type, before you hit enter. It will help you. You cannot really destroy anything because this is a virtual machine, so it is not going to hurt anybody. But I'm just telling you that remember to type very carefully, type very diligently, and read absolutely precisely as to what exactly it's saying. Because let me tell you, these command lines may be cryptic, but they are absolutely succinctly telling you what is going on. They will respond back precisely if you read carefully. They'll tell you what happened. And if you follow along, you will actually find success. That's the key thing I wanted to point out. Having said that, I need to go back to my folder called days, which is what I was working on. And that is the thing that I want to remind everybody, that you need to be working in the folder, which is the example that you're working with or the exercise you're dealing with. You need to be in that folder. So I just moved over there. I'm going to modify my screen display a little bit again, put this on the one half like that, and go back to my browser on the other half. And now, after having made sure that I am in the right folder, now I can type the command. This command is what you need to modify to include your token, include your SSH keys, include your preferred region. You may want to have it in San Francisco or some other location, your choice. You have to provide a prefix by the name days so that it helps you in further commands. That is, choose at least 8 GB size and point to this code sitting in the Contrib Digital Ocean folder. You can see that code sitting in here in the Contrib folder, Digital Ocean. You can run the same thing in other clouds. We are using to use the Digital Ocean cloud. So that's what we have chosen. This is the segment of code that will be used. You can choose to run in Linode or Google Compute Engine or Azure cloud or Amazon cloud or your local laptop. This is going to run it on your laptop desktop if you have enough memory and enough hardware to support. There are a variety of examples available, but I think this is the one that will help all of us specifically. So I'm using that example for this exercise. Having said that, I want to run now. I want to run this because I want to build a cluster that will help me take the next steps. So here we go. We are going to take that ready-made example that I have constructed by placing my token in the right spot, SSH keys in the right values, and then take this command and execute, like here in the terminal in the right folder. This is important. I should check my folder location is user days. Great. I'm going to execute now. It will go to DigitalOcean. Oh, I think I made a mistake. It should not say destroy, but say apply. Apply. This was a previous attempt that I was actually destroying. So command is correct. Actually, it says apply. You watch what you type. Exactly. So I typed, and then I watched that. It is telling me something else. I made that mistake, but then it prompted me. Are you really sure you want to destroy? I can actually say yes, because there is nothing to destroy, by the way. So it's already empty right here. I don't have any droplets. So there is nothing to destroy. But I should not say yes, because it's meaningless. I should say no. And so only yes will be accepted as a confirmation. So I can say no, or I can just break it. So I broke it. Now I will run the command, which is corrected. And it actually says apply. And this will apply the design that we have in our machine here. We'll say please apply. And here I'm running terraform apply. And thank goodness I did not make a mistake. And so here we go. It creates three machines for me. I will go and see them here popping up. I will also make sure that I'm creating zone entries in my new zone for the subdomain. So I'm going to set up the DNS properly. Here I'm attempting to write the things that I described to you verbally, is that you need to have a wildcard DNS record, something like asterisk.domain.name or asterisk.sub.domain.name. And I'm suggesting to use Google Cloud. And if you decide to create a subdomain, you need to create a name server entry in your primary zone. And this means you have to go to Cloud Player, and then in that Cloud Player location, log in to the right zone, and then in your DNS, create entries for name server for your new subdomain like this, one, two, three, four. Now, we know that Google is going to manage the subdomain called hello.cloudgenie.us. So we'll go to Google now. And there will be the zone entry for hello subdomain. In my example, I have done this so many times that I might have some stale entries, so let me clean it up. I will go to my networking section, and there I will find Cloud DNS. There is this zone called hello, which I want to actually start deleting a bunch of entries. For example, these entries do not belong. This is the wrong values from old attempts. These three values that I have put as a wildcard entry. This is the wildcard entry that I need to modify these values. They're not accurate anymore. So I'll say cross, cross, cross. Similarly, I will like to modify these three individual values I have here. They have three different IP addresses for the three machines that I have created in my virtual machine. I now have, I hope to have, three IP addresses. They are available now, one, two, and three. I can see them in my digital ocean control panel that I now have three IP addresses. So I'll put this on the side, and my Google console on this side, and then create four records, four. One for each individual machine, like one, two, and three, like that. And then one, the fourth record, is actually a wildcard entry, this one. I will create these entries right now, beginning with individual entries for all these boxes. First one is days number one. So copy the IP address, click. Take here to the days one, and edit that, and remove the old entry here, and put the new one, save. Number two, copy, go to number two entry, modify that. The old IP address is wrong. I'll put the new IP address, save. Go to number three, copy the new IP address. Number three, edit, and save. Now I have these three IP addresses correct. They match, 123.7, 166.89, 107.153. Those three match, but these values are still wrong. I need to make that correct. So I'll go modify the values. I have number three, number two, and number one. I have one, two, and three, all values in line in the order as a wildcard entry pointing to three different machines. When you have more than three machines, you will need to create a multi-entry for all the boxes that you have. Let's say you have 25 boxes. You need to have this wildcard DNS pointing to 25 boxes. They will show up here in DigitalOcean, one after the other, line up. That wildcard entry will basically allow you to run random applications and assign randomly generated names that all point to the cluster that you have at your disposal. That is what the purpose behind this wildcard entry is that only certain DNS providers actually support. Like you saw this Zone Electric or whatever that electric company was, it did not allow. That is likely to happen. Not every company will help you with this scenario. That is the problem that you will run into with certain providers that don't support these entries. You have to enable every machine to be included in the wildcard entry. That's what we just did. Moving back to here, we have set our DNS according to the instructions. You can see that your dig should point and resolve to give you a name server to the new entry called the Google Zone. Then in Google Zone, we have created entries individually for every machine like this, like I mentioned here. As a result, the picture will look something like this. That's what you saw. Now, we will go and validate and test. If you are doing this exercise multiple times, you are likely to have failures unless you clean up your non-host file. You want to go and clean up your non-host file like this. That file is in the SSH hidden folder and you clean it up. That will avoid some of the problems you may have if you are repeating the exercise multiple times. Now, you begin testing, is your machine DASE number one correctly configured? If you run this command like that and then execute the hostname command inside that box, it will respond back with the hostname. The response I'm expecting to see from this machine is DASE one. That's the command response to the command hostname. That's what I'm expecting to see when I run it. First, it will say, are you sure what you're doing? I will say, yes, and the response will be DASE-one. Here we go. We get the response back, DASE-one. Same thing again for other machines. The response we are going to get is DASE-two. It is actually responding with its own name. We are asking, hey, what's your hostname? It is telling us the hostname. The hostname happens to be DASE-three for this guy. It should say, my name is DASE-three, and it did. Here we go. We have succeeded in validating the DNS values. Nice. Now, we need to enable keyless logins. We don't have to type the keyname every single time. You can enable that by using what is known as SSH agent. You will notice that I occasionally type something like SSH and just connect. Boom, it connects without even having to specify my private key at all. This is because I have already taken that step to enable keyless logins because I'm trying to remember, have my terminal remember my private key for me. This is how you do it. This is how you do to make your terminal remember your location of private key. First, you have to evaluate your SSH agent. This is a required step. When you do that step, it will prepare your SSH agent to remember your private key. Here we go. That is creating an agent with a PID number, process ID number, and that agent will keep running to make sure that you remember the private key. Now, you have to specify that I want to use this private key, DASE private key, for my next subsequent steps. I'm going to say, SSH agent, please add this private key to your memory and that agent will keep track of the private key by itself. I don't have to type it manually every single time. Cut down my steps. That is what we are doing in enable keyless login, cutting steps. Here we go. We added the identity, which is our private key. It sits in the home user home location in the.ssh folder in the name DASE. That's our private key. We have assigned that and made sure that SSH agent remembers the private key. Next, we should be able to go back into our folder, which is where we are already. We are already in there. Next, export this reference. Yes, go ahead. Is the agent a process that's then running in the background? You are evaluating. It's already running. You're getting an evaluation right now. This evaluation happens to make sure that you are actually running. Yes, it is running. It's a process that starts up when the virtual terminal starts up? Yes, correct. The idea is to invoke if it is not running, invoke it. That's what your evaluation command will do and expose the paid number for you to refer. You can actually examine any processes for that name. You can see that the SSH agent is running with the paid number 3242. That matches what you saw here. It is running in the background, keeping track of your private key for you. Okay, thanks. Now, next step, setting up a tunnel so you can actually communicate with your cluster. We're just using one of the machines to connect and establish our tunneling. This is how you establish and export and declare that I will be using this day's number 1 as my tunnel. Here we go. We export that value and declare your variable called dayctltunnel variable, which happens to be the machine called days1.hello.cloudgp.us, which happens to be the machine that you already know is in DigitalOcean. You can see where it is by going to that box. It is this machine that we're talking about, days1. This machine is what is going to be our tunnel into the cluster, which is these three machines. Now, proceeding forward, I want to list out what do I have right now in my platform. I will go and see I have nothing. It will show us nothing. That's what you see, nothing. The result is empty. That is expected because we haven't actually installed the platform, but now we want to. Here we go. I think I moved my mouse incorrectly. Let me go back to the right place. I'll click here and make sure that I'm actually running that install and start the platform as a service. Here we go. First part is to tell the platform, I'm going to use my private key, which is going to be this one. I'm going to use this private key. Here we go. Remember. It remembers. I'm also going to tell that I'm going to use the sub-domain hello.cloudgenie.us as the basis, the foundation of the platform, as the foundation on which I will then install applications. I'm setting the platform domain name to be hello.cloudgenie.us, which is the second step here in this box. Clean up and run the second step. I am defining the configuration platform to be set as the domain name hello.cloudgenie.us. Set. It sets it. After having set my private key and declaring my name, I will use with the platform as a service. I'm going to now install the platform like that, which is already locally available in the source code. You have it here. You just invoke this. I will now install the platform on those cluster that you have here. This cluster is actually installing the platform right now. You're setting it up. And then if it fails, I hope not. But then if it does, you should run this command. If it doesn't fail, you should move on. I think it will not fail. And it did not fail. If it does fail, you should refresh the units. This is not required anymore because it did not fail. You saw that it succeeded. It is telling us that I have installed the storage subsystem, the logging subsystem, the control plane, the data plane, the router mesh, and I'm done. Now it says, please run this command to start the platform. That is the command. Next, days start platform. By the way, it will take about 15 minutes or so, just so you know. So I'm going to copy that command and run it in that platform. Let it go. Count the time is 4.55 p.m. right now for my time zone. And so we will revisit this in about 15 minutes. We'll leave it running. This is a process for the platform to be set up and configured and run and all that good stuff. So we are building our own Heroku. Now we will change our function, our role in life to become developers magically and then take some example application and push. This time, we will push it to our own platform. Once it becomes ready, we should be able to push and see our applications go live. We'll also be able to scale out horizontally and increase the number of Docker containers it runs laterally, horizontally, like scale out. And we will do that exercise in just a few minutes as soon as this thing finishes. So once it finishes, you should also list again and it will tell you what is running and what is going on and all that good stuff. You will see that. In this time, I think it's a good idea to take a short break. So we'll take a break and wait for this to finish. But it should be finishing in a few minutes. So I'm starting my timer for a break. And here we go. So the break has started. Okay. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Sounds like the timer was a little quick. Yeah. It just went off. So we had a 10 minute break. The thing takes about 15 minutes, as you know. And so it is finishing up as we speak. You can see that it is proceeding forward and it finished. It took me about 10 to 15 minutes. I timed it apparently. I've done it so many times. A variety of exercises. I just know how and things will work out. So it just finished successfully. And what does that translate to? That we have our own platform running. I hope you can hear me. I think you can hear me. But I'm not wearing the microphone. That's clear when you wear the mic. Yeah, much, much clearer. I know. It's better to mount it here instead. So as you can see that this day's platform is now running for us. You can see that it did a bunch of things. When I started the platform here, this platform started the platform. It started the platform. You see that it built our storage subsystem is active and running. Lower logging subsystem active running. Control plane active running. Here it was loaded. And here it is active and running. That's the difference. This is installation here. This is actually execution. So now the platform is up and running. We should be able to set up an administrator login onto the platform. But before I do that, I just want to quickly do an inventory of what did we do. So we can go day's control list. And that listing here will list out all the services that we have running. And this is not going to be empty this time. There are lots of things loaded active and running. You can see that. I can minimize or maybe make the screen a little bigger to see like that. And run it again. And you can see that we have a bunch of services up and running and active. All of them, by the way, which is the good news, absolutely good news. Now, next, I want to establish an administrator on the platform. Nilesh, one question. Yes. The services that you see there, are they running on the next server like a service or are they running in the command prompt? They're running on these three droplets. Okay. We have nothing running here on the local machine. We have nothing running. In fact, we are done with that folder. We don't need to work anymore in that folder because the work of installing and bringing our platform as a service has completed. Now is the time to use our platform. Before we begin using our platform, we need to have a login name and a password established for the super administrator. That is what we will do next. So we will use the Daze client to register the platform. And here is the command, Daze register and that link. So we'll go and type the command and it will say, okay, give me a username. So I'll give it a username that I like. My username I like is Nilesh. You can choose whatever you like. So here is my username. It says, give me a password. So I'll give it a password and then password again. Then I give password again. It says, give me an email address. So I'll give it my email address. And by the way, who is asking these questions to me? The platform as a service. Who is running the platform? Me. Where am I running? On my own infrastructure. Where is my infrastructure? My infrastructure is here. I can choose any cloud I want. I can choose a bunch of machines in my garage if I like. As long as the DNS resolves properly, I have no problem. As long as I have a good internet connection in the garage, by the way, I actually have such a setup here in the garage. So I've been doing this for many years. But what you're looking at is I'm going to give it this email address. And then it says, OK, registered Nilesh and logged in as Nilesh. So I'm logged in on the platform. This is like Heroku login, except we are using Days. So it is Days login. We are back here. We have established a connection with our platform. Now we need to send our public keys to this Days platform so that we can now become a developer and deploy an application as an example. So we need to provide our public key to them. Just like we go and give public key to DigitalOcean or Heroku or any other cloud service provider, this is a cloud service. We need to go and provide those keys. So first thing first, we are basically done with that Days folder. So we should come out of it. We should say go to our home location. So we are now in the home location, CD tilde, PWD, home user. That's our home. Now in here, I want to go provide my keys to the cloud, to the private personal platform as a service. It should not be called personal. Actually, it is personal right now, but it's the company that will use this as your own platform. So that command that I'm going to type is very, very similar to the other command that you may have run in the past, Heroku keys colon add. This command that you saw, and I remember you ran it before, is to provide your key pair to Heroku. You've seen that. You've done it before. Very, very similar, except instead of Heroku keys add, we are going to run Days keys add. Very similar idea. And off we go. It says, okay, I find your two keys. Which one do you want to use? So I'll say, you know what? Number one looks good. So I'll choose number one. I can choose number two as well, but I'm just saying number one. Number one, your choice and your developer's choice, not your developer's choice. So you're now a developer. So you're going to deploy an application. The developer decides to use a key pair. The developer chooses to use the key pair called this, or you can use this, or you can use another one. It's completely up to you, and that is what we are doing. So when we do that, it is going to send our public key over to the platform as a service. One key striking difference between this platform as a service and this platform as a service, Heroku, the difference is Heroku has a user interface in a web browser. Days does not. There is no such thing. If you open hello.cloudg.us, you will find nothing, because there is nothing visible in a web browser. There is a complete service running. Yes, you can deploy the platform, but in this location, there is nothing. You will have something in another location like here. You will get something there, but not in line number 18. 18 will be nothing. I mean, you don't have a user interface. A fancy, user-friendly user interface does not exist with Days platform as a service. They don't have it. They don't need it, because they believe that developers don't want it. That's their choice, and we understand that choice. Therefore, when you open that website in line number 18, nothing opens up. But don't worry, the service is running, and you are connected, although nothing shows up here, which is fine. That's the design. That is how they have designed it. Having said, we want to now become a developer. We will magically get some application, which I have already given a ready-made application for us to play with. We will just use that application. What we will do is go to our workstation. By the way, make sure that I fill out this key choice. I'm going to select the key number 1, and I'll say OK. It uploads the key to the Days platform. I said number 1, so it chooses that key, number 1, days.pub. It sends that public key to Days, and done. It did that. Now, we are back in our home location, tilde. Here, I want to now become a developer. I need to have an application that I can just throw and push at the Days platform. Let us cheat and get a ready-made application instead of writing one. We can write one, but we just get one here. It's coming down. It came down. The application is called Example Ruby Sinatra. That's the name, the application that I have written for us to play with. This app is available locally now in this folder, Example Ruby Sinatra. You can see that application listing, Example Ruby Sinatra, came down. You can see it in the tree form also, tree-l 2, maybe 1. It is too long if I go 2. This folder contains that application that I just downloaded. I'm going to go into that folder, Example Ruby Sinatra. Now, in my current directory, sorry, Example Ruby Sinatra. Now, my current directory is pwd. I am in the Example Ruby Sinatra folder. There is where my application sits. This is the application I want to deploy to the platform that I just developed and deployed. I will do that. What I need to do is that I need to provide a Git remote connection so that I can push my application to my own platform. You remember here when we had an application, we said you can push it to some remote. We choose the remote of GitHub and we push, then it shows you the application source code on GitHub. That's the purpose in life for GitHub to be able to allow you to share source and collaborate and merge and pull request and all that. You see the source code here. On the same application, if you set up another remote, such as Heroku, and you say push, it sends the code over to Heroku, and you will see a nice user interface running your application. This time, we want to create a remote. This remote connection will not be with Heroku but will be with Days. We want to push. We expect to see a nice user interface running our app. That is what I expect to see. We will have the app. We have it, by the way. We downloaded a ready-made application. We want to be able to provide a remote connection to Days and then push, and then we are done practically. Here, what are the remote connections I have currently? Let us examine. Currently, in my example Ruby Sinatra application, my remote connections are only one, GitHub. That's where it came from. This thing came down because we cloned it here, clone. It came from GitHub. You can make a change and push it to GitHub, but that's not the point. You want to establish a remote connection with Days. We will create a placeholder for this application in the Days platform. This is giving it a room for it to go and live. Our idea would be our application. We want to establish a remote connection with Days platform. We are creating a room for it. It already has a remote connection with GitHub. That is where it came down from because we cloned it. Now, at this time, we want to establish a new remote connection with Days where I want to push it. This new room can be created on the Days platform by running a command that says Days create. When you create this room, it also establishes this remote in the application. You will see that. Right now, we have just one remote. You will now see this one remote expand into another. As soon as I run Days create, Days create. This create is basically make me some room in your platform, please, because I want to come and live there. I want to push myself over to your room. Make me some room. Here we go. It created a room for us. It says, creating an application, done. Created a room called Quaint Insignia, randomly generated name. Git remote Days added. Remote available at this location. It told us the remote connection is established. Let's go check the remote connections now. We now see that there are two additional remote references that point to Days. One for push, one for fetch. We already had only two to begin with. One for fetch, one for push for GitHub here. Those are the same one here. The new ones that are added as remote in the name Days. Days for push, Days for fetch are newly constructed remotes added by the command Days create, which created a room, a place for this application to go live in the name Quaint Insignia, which means our application will be live on that location with that name. Once we push, we now have a remote, an additional remote that points to Days, an original remote that came from GitHub. We can push it to GitHub and see the application there, but that's not what we want to do. We want to push it to Days. We are ready for that. Let us see. I want to actually push to Days my master application. Here I have this application. I'm going to push Git push, send it to Days, please. Send the master branch, please. Git push, sorry, hold on. Git push master branch over to the Days remote, enter. It says, I don't know what you're doing. I say, yeah, I know. Go ahead, do it. Push it. It pushes. The remote is Days, our own platform. It will receive this application, install the application just like you would do locally. It is doing a bundle install. It detected a Ruby application. It is going to compile Ruby, choose this version of Ruby, install the rack, install these gems that are needed, and it is proceeding further. You can see that the build will finish. When the build finishes, it will tell us what to do. It will basically say, you know what? Your application is live and running in the home you created for this application in the name Quint Insignia. It will successfully build the image, build the application on the new location, the new home for it. It will report back success in just a minute more. Once we have that, we should be able to open our URL, which it will return back as a pointer. We will expect to see something like Quint Insignia.hello.cloudgini.us. That will be the name that you will see coming back from the push command, which pushes the application. It will tell us, you can now open the website that shows you your application live and running. We will see that as soon as this thing finishes. It takes one more minute or two maybe, but then we will have it completed, and when it does... It's using the word container there. Is this container something we could push to additional destinations, different servers? Yes, except you don't want to because it is even further abstracting the concept of containers away from you, simplifying your life. All you need to really do is push the application. Don't even worry about Dockerfile and containers. Don't worry, just push. That's the core idea behind this thing. It is using containers under the hood. You will see that this build process finishes and the application goes live under the name Quint Insignia.hello.cloudgini.us. Then your application is live. It will be running inside one container. You want to add more containers, no big deal. You can just scale it up. I should say scale it out like this. That's it. It just builds you in three containers. You want to do more, you can do further scale. Don't feel limited. We have enough horsepower on the machines there, three big ones. It is sufficiently large enough to handle any workload, and you can scale it out to a comfortable level. It will work. You can have 50 containers running, and it will scale out to 50 different containers just like that. You will see as soon as it finishes, which is going to take a little bit more time, but it will finish. When you're scaling out, you're actually scaling out on those three droplets you've got, not adding additional droplets? Three containers, correct. Not adding additional droplets, but we are limited to the capacity provided to us by those three big boxes. Three big containers we have. That's the physical limit. You can, of course, throw more money and get more nodes, and then your infrastructure becomes bigger, so your cloud becomes bigger, your platform as a service becomes bigger, you can accommodate more containers and all that. Let's recap the discussion, which is basically here. What we just did is we began by using a source code of an open source platform as a service. We then choose some infrastructure provider and said, you know what, give me some machines, three of them to begin with. We can choose more and then run this software on top. This converts this cluster into a platform. Then we take an application and throw the app on the platform, say push. It gives us a URL called quaint insignia.yoursubdomain.hello. Like that. That is what you see as the URL, which is where your application should become visible. Let us attempt to see the application by opening that URL right here. It is, I think, getting stuck, but we'll find out. It should have succeeded by now, but no worries. We will open our, what was that, quaint insignia.hello.cloud.us. There is something, but it is not found. It is not completed. There are actions that are needed to make things happen. That action has not completed. Intermediate steps, you can see that it has built up a server, running NGINX in a container, but the actual application hasn't successfully loaded yet. I am getting anxious because the thing doesn't work. I need to make it work, which I can do by breaking and running it again. As simple as that. What I would like to do is, since I am losing patience on this getting stuck, it is trying to push and not work. I am going to break this just like that and then push again. It says fail to push. Another git push is going on, aborting, so it is not behaving properly. However, we can fix it. Let me tell you how to fix it. I attempted to push one more time and it fails because it is saying that another push is going on. You can basically get rid of this situation by creating another folder containing your source code and treating it as a new application. What does that mean? You can come out of this folder and remove or rather rename the current folder we have. Currently, we have this folder called example Ruby Sinatra. This is the one that got stuck along the way as we were trying to push. We will rename this folder example to something like broken because it did not work or got stuck. Rename it, make room. Ignore that. You can kill the container, kill the room in a separate attempt. Then go back here and clone your application one more time like that. You get fresh source code. You are going to go back in your folder. At this time, the folder is called example Ruby Sinatra. The earlier example was got stuck. We will ignore the got stuck piece as is. Leave it alone. We will go inside the example Ruby Sinatra folder and say, you know what, they create a place for me. This is the different me. The one that we had before was the one that got stuck. We are ignoring that. Here you go. I have a quirky jokester created for you. This quirky jokester is going to be the room name that we have added a new remote for. We will go and check Git remotes. We see that this remote is available in these for push and fetch. For push and fetch. Same with GitHub remotes. We can now push to this location simply by saying git push days master and repeat the steps that got stuck in the earlier attempt. This is going to push the same thing but in a different room. The name will be whatever that jokester name. Whatever that name was. What was it? Quirky jokester. This DNS name will resolve to the application. I hope this one does not get stuck. If it gets stuck, I have to diagnose as to what is going on under the hood. Something may be wrong in the application or something else. I'll diagnose that. This can take time to actually understand what may be causing the build process to get stuck as you push your application. There are lots of things to study and understand. We may not succeed on this particular step but that's the point aside. It might actually work out. It may be a transient issue depending on what that situation may be. The point behind this exercise is that you get to choose whether you deploy your own platform on a given infrastructure or you choose to use a ready-made platform like Heroku, like Engine Yard, like Amazon, like Google, like Microsoft. Everybody provides their platforms. This Heroku thing is the most well-known example of it but you can choose to go with a cloud service provider that is giving you a ready-made platform if you like. If you choose a cloud provider, you have to follow what they require and only those applications that fit their requirements will be able to run successfully if you are on your own. You have a lot more freedom. Freedom comes with power and power comes with responsibility, which is you have to manage it. If it doesn't work, your butt is on the line, bottom line. That's the bottom line. If it doesn't work, nobody will blame anybody else except you. That is a trade-off. If you know what you're doing, you can actually save a boatload of money. That is the reason why many companies are using private platforms as a service. An example is this commercial application, Apprenda. Another open source example is Cloud Foundry. There is a chat message. It's about something else about licensing. Oracle Cloud Licensing policy, double the number of processor licenses needed by customers that run AWS. Licensing is something that I would rather not talk about because it is commercial in nature. I don't talk about licensing. We'll talk about that later, but not right now. I thought it was similar to the concept you were talking about. Please elaborate. Is it similar to if you go to a platform provider, the cost can go up without any advance notice or they might suddenly say that now very crazy. You're absolutely right. In fact, there is this lesson that I have learned a long while ago and that I have documented here in this location where I basically describe the same issue you're talking about is the idea that you need to remain in a position where you can avoid vendor lock-in. That is a critical thing to remember when you're going through a commercial service provider like she was suggesting that a provider can jack up the prices. They just did that in the link that he's telling you. Let's open that link. I think it's a valid point. Here, the news is Oracle cloud licensing requirements doubled for Amazon and Azure users. Magically, it increased the price for no reason other than that they want more money. If you're stuck with them, you're screwed. There's no easy way for you to just walk away. That is the core concept behind this idea called fungibility. The idea of the word fungible is an economic word, fungible. What does it mean? It means something you are able to replace or be replaced by another identical item. In our context, we are talking about fungible clouds, and that means you can replace one cloud with another with little to no extra cost, extra effort. You can do that provided you are following a common set of standards for you, provided you are designing your applications that will run on more than one cloud provider. You have a choice to go away from one provider like these guys who want to jack up the prices. If they double the price, you just go to a different cloud. By the way, many companies that do not do this actually fall victim to what is known as price gouging. Basically, you jack up the price like this, which is technically and economically okay. It's a business strategy. But if you are in a position which gets you stuck with that scenario, it impacts your bottom line, and I'll give you an example of how it does. Here, there used to be a cloud called Google Compute Engine. It's still there, by the way. No, not Compute Engine, App Engine. This App Engine is a slightly different cloud than the Google Compute Engine. What this does is it follows a slightly non-standard way of running your applications. If you are able to fit that design, this used to be free like five years ago. You run your applications, Google App Engine will let you run for free. I used to run my services here, and I had lots of customers using a different application prior to what we are doing right now. One fine morning, I hear news that they are going to charge money, not little money, but big money, just like this, just like what she was suggesting. That basically hit so hard that I had to actually stop running that application completely. We walked away from discarding the application and stopped doing anything with that, completely ignored it because we were not in a position to go away from the clutches of this requirement. The App Engine required a specific way of writing the application that allowed us to run here for practically free. We did not have the liberty to walk away, and that was a lesson I learned about five to six years ago. But ever since then, what I have been doing every time I build something, I will run in a fashion that is totally portable, literally portable, so much so that you can see me in one example coming up at some point. This entire site that you have, this entire site, which are about 13 or 14 containers running here, I can literally forklift this entire infrastructure from here and go to a different cloud in a matter of 10 minutes, one command, and you will not even notice. You will see this live example. I will do this live with all of you watching. In 10 minutes, we'll switch one cloud company to another, and you will not see a blip, not notice a blip. You will see it. You will not notice a blip. You will see that your sessions are migrated, your logins are migrated. Everything else just works. We actually will change cloud. Right now, we are running this thing on a cloud called Vulture Cloud. We will switch over to DigitalOcean, no problem, or even within Vulture from one machine to another machine. It migrates so smoothly, so comfortably, because we do not tie ourselves with anything that is unique to a cloud provider. The moment you do that, you get married to that cloud, which is exactly not what you want to do. You want to not get married, and you don't want to get stuck with this kind of a scenario, which is unfortunate. Keep your cloud fungible to the extent you can. It helps you. Let us see if that thing succeeded or is still getting stuck. I think it is still stuck, but let's examine. If it is stuck, we'll move on, and I will diagnose it later. It did not. It failed, apparently. It said something is happening here. Hold on. Let's see what's happening. Let's read the error. It says, successfully built, and then it is launching. It says, error, failed to retrieve configuration from controller, and SSH, remote rejected, failed to push some references to this location. Let us see what that translates to. Is it actually failing or is it just telling us something did not work while actually it may be working? We'll go here and open our quirky jokester and see what we see. We still see the problem, which is it is not successfully running. We are expecting to see it run. It doesn't run because of the failure, and the failure happens to be something failed in retrieving configuration from the controller. That is what happened. I will leave this running one more time, and then I will change topics to a different discussion I want to have. I'll leave this one more attempt and leave it running and see if it succeeds. Otherwise, I will diagnose this problem later on. I'll modify this example application. It also did not work. The reason was failed to retrieve configuration from controller. That was the error. We'll leave it alone. We'll do another git pull or git clone and go inside and say, git days create, and then we have a new name called upbeat tabletop. Then we'd say git push days master and leave it running, and we'll discuss the next topic. The third time I hope it works, but if not, we'll have to diagnose. I'll do that later. In the idea that I want to be able to prepare for the next set of sessions that we have, let's recap as to what we did in the cloud technology segment. Back here in our cloud technology segment, we covered this. Go ahead. In the exercise that you just did for the last section, can you just do a quick overview, like a minute overview of what we did, like DNS changes. I will do that. So I understand the overview of it. I'll do that. We began with discussing the need for a platform because it helps our developers. Our developers need that flexibility to just push something to the platform and expect it to run. The problem we are running into why it doesn't run maybe with the application, maybe with something else here, or maybe with the underlying infrastructure. We don't know what may be the issue, but that is what we will diagnose later on. The reason we deploy our own platform as a service is to gain independence from any one vendor, remain neutral, remain agnostic, and not get married with a cloud company. That's the core idea. As long as you have your application that fits the requirement of your platform, it will work. So with that idea in mind, we began exploring. Nilesh, quick question. How does PaaS could actually be a server in Amazon Cloud or could be in Microsoft, in Azure, or it could be your own machine sitting under your desk? The whole machine at your desk is not technically a cloud, but yes, you can get it to run. It will barely run. And when you want to use the home desktop, a bunch of machines in your home or your garage in your office, you can use this Vagrant method to simulate a cloud. If you are in the OpenStack private cloud, you need to use this set of code. If you are using the Linode cloud, you will use this set of code. If you are using the Google Compute Engine, you will use this code. If you are using Docker Registry, you will use this code. We use DigitalOcean as an example. The code uses CoreOS under the hood. This is just a version change, I think. If you are running on bare-meter machines like physical boxes, you will use this. If you are running on Azure Cloud, you will use this piece of code. If you are using Amazon Web Services, you will use this piece of code. So they have given certain specific examples. And that is how this particular platform has been built. You can choose to see how other Cloud Foundry as an example. And you can go to Cloud Foundry as their source code is available in somewhere. Where is that platform? Get started, download, and there should be a link to GitHub. And so here is the Cloud Foundry release, the Cloud Foundry website on GitHub, where they have a bunch of different Git repositories. It's fairly complex, even bigger than DAIS is. And so it takes a lot of time to deploy all these things that are needed to make a good platform as a service available. And this exercise we cannot really finish in a class session like this. That's why we do not use this example. But that is what Boeing is implementing internally. Now, your question regarding can you run DAIS? Yes, you can wherever you feel like as long as the source code provides support for that. Similarly, other Cloud providers will have their own solution. Like DAIS, like Cloud Foundry, there is other solutions like Flynn, for example, is another platform as a service solution. Not this guy, but this product. So throw away the duct tape, say hello to Flynn. That's the idea here. And it is also open source. And you can pretty much do the same way. The core idea is very similar. You get to the source code on GitHub and you run Flynn. Like DAIS, like Flynn, like Heroku, like Cloud Foundry. All basically operate the same way. The fundamental ideas are you are giving your developers the ability to run applications on demand by just a push. That's the core idea. To enable this scenario, you need to run some platform software on top of some infrastructure. Not just one box, but a bunch of boxes that you have to get and run your platform solution on a cluster of machines together. And when that needs to happen, you need to make sure that all these IP addresses individually need to map to a common wildcard entry. Like that. This wildcard entry is what allows us to run something like here. What was the name we used? Jokester or something? What was the names that I have here? Let's go see here. You know what? That thing succeeded. This thing seems to have succeeded. Let's go find out this has a name. Let's go upbeat tabletop. That's the name we got. It seems to have succeeded, successfully deployed. Beautiful. What does that mean? Let's go see that first. We have that thing running. It reported success. Now, what does that translate to? It's just like Heroku, we have days running our application in a name given to us called upbeat tabletop. I would like to go to this URL, upbeat tabletop.hello.cloudjini.us. That is where it is telling us that the application is actually live and running. I will go to that link. You can also type days open to open that link automatically in a browser. It opens up like that. Here you will see the application running. It is actually running and live. You can see that it is running on this container ID. That's basically it. This is the application. It is actually live and running. However, I want to make this application a little bit bigger. I want to go and scale the application. For example, here, click and scale. Scale as in make it bigger. I will like to scale that pretty much like here. Scale your application and this will add more containers to your application. Right now it is using one. I will scale the application by running this command, go across three containers. Here we go. In our command line, we will say exit the browser. By the way, note this number 7541. Remember that number and ending with BA. Just remember that. Closing the browser. Now scaling to three containers. It says scaling processes. But first, coffee. It basically says give you time, get some coffee, come back, and I will have it scaled. It will scale out automatically across three containers because that's what we said. Three containers. Is it going to put a load balancer someplace? Yes, exactly. It finished that very quickly by the way. We have one, we have two, we have three, and a load balancer in front. Now we can say days open and you see that it is giving us a container name. 7541, blah, blah, blah, ADBA. Now I will refresh and you see that the container ID will likely change. It is going to a different container every single time I hit. There are three of total, three total containers. Let me give this link for you to play with. Here it comes in Slack chat. The link is here. Hit it. You will find different containers rendering the application for you. While it is doing that, I will scale this. This time, I want to scale it not to just three, but 33 containers. It is going to scale. You will see 33 different containers serving your application. Our machines are, I think, big enough to handle 33 containers. No big deal there. It should do that. As soon as the thing finishes, you will be able to hit that link. You will see 30 different container IDs popping up the same application at the moment that you click. As soon as this finishes, you should be able to see that response coming back. We have scaled it up to 33 containers right now. It is all of them up and running. Here are the guys. You should be able to hit and see what happens. Hit this. It gives you your container ID like that. Hit again. Refresh. You will get 33 different identifiers showing up because those 33 containers are what are actually serving this application right now. You get the point. Scaling is effortless. Pushing is also somewhat effortless. Somewhat because we failed twice. Third time it was charred. It may be in the process of I don't know. I need to diagnose as to what. I will go and read the logs later on, but it worked on the third attempt. Why did it fail on the first two? I have no idea. I will find out. Bottom line is back in our whiteboard, we took three boxes here. Those three boxes that we took are days one, days two, days three. We got three IP addresses. We put them in a wildcard entry like that. We also created individual entries like days one, days two, days three. Then individual DNS entries. We created these entries in Google Cloud, Google DNS, for example. Before all this, we chose to create a name server entry for the subdomain in our primary zone, which happens to be in my example, Cloudflare. In the Cloudflare DNS for this subdomain, I had a name server entry that points to this guy so that this activates. When this activates, then all these subdomains suddenly start working. When you throw an application here on the platform, you will see that it gets a randomly assigned name, like in our example. What's the name? Upbeat Tabletop. Upbeat Tabletop is the name it got selected and then we got that name assigned. Upbeat Tabletop.Hello.CloudGenius. This string was randomly assigned to the application that we pushed in the third attempt. It maps to your wildcard entry. That basically allows it to point to any of these boxes that you have under the hood. That gives you the flexibility to scale your containers across any number of these boxes that you have. We just chose three. You can have hundreds or more, thousands. They will scale comfortably. Then you have a very large cloud like that. These applications that your entire company can deploy applications, each one of them, and run it across multiple containers, scale it out, scale it back in on demand, just like we did here. I'm scaling it up to 33. I'll scale it down to 10. Shrink it. I don't need any more, that many. It shrinks. Here it did, shrunk. No big deal. Obviously, you can scale it to say 55, and it will scale to 55, whatever. As long as it is not, I don't want to overload the three little boxes we have, or rather I should say three big boxes we have. I can actually bring them to their knees if I say around 1,000, scale to 1,000. I think I will crash the system. I'm very likely. I will give it a shot, by the way. I'm going to give this a shot. See what happens when you scale to thousands of containers on just three boxes. See what happens to just gauge how much can you push. I will do that as soon as this 55 finishes. I will next step run 1,000 and see what happens. It will probably bring it down to the knees, but let's see. This one works, 55, no problem. We'll just test it quickly, refresh, refresh, refresh. It is giving us unique numbers. Unique container IDs are popping up. That's good to know. It is working. Back in here, I'm going to now really crash the system by scaling it to 55, or rather 6666. How about that? Really large number. Throw at it. See what happens. It will break. Very likely break because all your three machines, but let's see. Give it some time. We'll figure it out. If it doesn't break, we are not really hitting the hard limits. We'll figure it out in that part. Next up, the discussion that we were having here. Five-minute break. You want to break? That's great. Five-minute is good. Here we go. Timer, five-minute break. We'll continue after that. This can be a tricky exercise to run. Getting it to run, it involves a lot of patience. I know when most of you, when you run it first time, you don't have patience. That's okay. I have enough patience for all of you, so I will help you in making it work. I have no problem with patience at all. I don't have a job to go do, so I do here, do this one thing with you. I did get it mostly to work. I did catch myself though I had earlier used themans.com instead of themans.net. That does matter. Okay. People are known to make mistakes. We are humans. We are supposed to make mistakes. What's the big deal there? I'm going to walk around the block. I'm going to walk around the block. Okay. Okay. Okay. Okay. I've got another off topic question for you. When you signed up for the Microsoft Office, did they give you an option to select Vizio? So you're asking me specifically? Yeah. Well, because I went into our Microsoft Office 365 that we've got through Cloud Genius, and it does not have... I don't remember anything, so I'll go and find out right now. So let's go there and find out. I have no idea what I have. So let's go log in and figure it out. I don't remember because I don't use Microsoft Cloud much. Yeah. I'm just trying to find a drawing tool. I'd like to... I can give you a drawing tool. No problem. You want a drawing tool? Use this. You can log in using your Cloud Genius email and it works for free. I'll give you a link in Slack chat. So here we go. There's a tool here called Lucidchart, and you can draw diagrams and illustrations. You can log in using your Cloud Genius email that you might have already, and then it is free. Excellent. And so the idea behind this one is you can draw like diagrams like this. That's what I think you want to do, right? Yes. Yeah. Go ahead. Use it. I think we just timed out. Okay. Yeah. Try this. Yeah. I have a message for people who are new, specifically Josh and Charles that just joined. There is a concept called a school account, a school email address. I think I need to create that for you. The explicitly clear benefit of using a school account is you get unlimited storage in Google Cloud, Google Drive. That's a tangible benefit. Apart from that, it's kind of pointless. If you want it, you can get one. Another benefit was using a diagramming tool. Lots of these things are free services available to you as a school student. Even after you finish your Cloud Genius program, these things will continue to be free because Google and Microsoft and Facebook and a bunch of other companies have provided their services to educational institutions like Cloud Genius. They don't charge us, so I don't charge anybody. And it is there for you if you want to use it. If you want one, please ping me on Slack chat. I will create an account for you. If David wants to use a diagramming tool, there is Lucidchart and it's available. Next. We see that this has scaled up, not yet, it's still getting stuck at getting scaled to a certain number of containers. It's going to be taxing, I'm pretty sure. But let's see how the machines are doing under the hood. Let's go to DigitalOcean and find out what the machines are doing. How is the network characteristic? How is the performance of the CPU? All the droplets are here. Let's go to machine number one. What are you doing, dear droplet? Let's go see. So the CPU consumption is pretty heavy, as you can see. The disk IO is not much, but half the CPU is occupied. Let's go see the other machines. The other machine number two. Machine number two has the CPU almost busy up to 75%, 60-75%. Let's see machine number three. This machine three is also probably very likely busy on the CPU side because it is spinning up 6,666 containers right now. And from here, about 40% CPU consumption. And this is what is going on and the machines are busy doing the thing. And it might succeed, honestly. But we don't know. I have never tested at that limit, never, never actually found out what the limit is going to be. So we will find out today if it succeeds or not. I'll just throw a number at it. This is probably a big number for three boxes, but we'll find out. OK, so back here. When you have multiple machines that you want to be able to configure and each of these get an IP address that you put in a wildcard entry, .hello.cloudgenie.us, like that, then when you throw application one here somewhere, it goes to the cluster. You don't exactly get to choose which box will run your app. It will be dynamically adjusted and fronted by a load balancer that you will receive this reference in form of a name. Like the name we have is, what's the name we have? Upbeat Tabletop. So you get upbeattabletop.hello.cloudgenie.us. That's the name you got. It was dynamically assigned to this application. And that's the mapping in DNS perspective. Under the hood, what these boxes are doing are each one of them running Docker containers, all of them. And what Days is doing is dynamically allocating specific containers for your application, assigning them this name and fronting them with a load balancer. So it will look something like here, where you don't have, let's focus on one segment. So just you have this segment, for example, like that. And in there, you might have, say, those three boxes. Inside those three yellow items that I show are actually three boxes. And these little items in there are containers. Think of it like that. And here, you will throw an application. So this is you. This is you. And you throw your application to go on the Days platform. The platform decides where your application is actually going to run on which container to begin with, one container. So that might decide that this container will run your app. So it says, OK, I will do the network mapping between your upbeat, whatever that name was, tabletop. And then that mapping goes to this container. And that's where your application runs. Beautiful. And then you decide to scale. Scale web equals three. So what it will do is actually put this application into one more container here and one container here. And then load balance among these three under the same name. These do not exist yet. But when you scale it up to 55, it will create 55 containers, divide it among three different nodes almost equitably, almost. And then in a scenario like that, you will have these three yellow boxes scaled up to run 55 different containers. And then running your application will look something like this. Each of these yellow items are actually a box representation. So focus just on the blue item here, inside this blue oval. The three yellows are our three boxes. And then we have 55 containers running, each one of them running a copy of our application and getting served by a load balancer to these customers. That's what they see when they visit upbeat tabletop on your three machines running your platform. So you are outside here, but you are able to inject your application by a git push. Git push days master. At this moment, what we have said is that I want to scale equals 6666, which is an enormously large number for just three boxes. And so it is creating these containers right now and getting busy doing that. And it might fail because it is way beyond the capacity of that machine set. But we saw 55, no problem. I have never actually found out the threshold, how many will work on just three machines. But today we might eventually find out. And when that happens, I'll tell you how much was the threshold, whether it succeeded or not, it might take a lot more time than this. But this is actually ridiculous to run it like this. I'm just doing it as a test case to find out what's the boundary. Nobody would run 6666 containers on three machines. 600, maybe yes. 6000, probably not. OK, so I think I'm going to close out on the summary discussion, which was happening in this sheet of paper. And so did I miss anything in our discussion? That's what I'm trying to remember. I think the question that Raj had was to summarize quickly as to what did we accomplish. So I think we did that. I think we did the DNS explanation, did the deployment application discussion. And the scaling discussion that we just discussed. That, I think, concludes the concept about using platform as a service on your own infrastructure that you run the platform itself. We started doing this specific exercise on demand by Hitachi Data Systems, who are in the business of selling hardware. What they do is sell compute, storage, and network gear that they actually sell hardware. They're competing with Amazon Web Services. And Amazon is so damn cheap that it's difficult for Hitachi to sell their hardware. So what they are doing essentially is to sell the hardware, but then bundle services that I will provide you a ready-made platform in your company. I will give you a ready-made virtual cloud in your company like OpenStack, for example. I'll set up Daze as a platform for your company or set up Cloud Foundry as a platform for your company. But please, please, please make sure to buy our hardware. That's what they're really trying to accomplish. So they demanded that we build a solution for them. So we focused on using Daze as an example for the, I think, three or four classes ago. This particular exercise is a relatively new one in here. And this write-up that you have is fairly fresh. It's a new exercise basically created on demand by past people who are attending the program. Hey, can we do this? So we did that. Having said, I would like to ask you if you have something that you want us to cover, I will absolutely include that. What we want to actually do now in the time that we have is to give you another flavor of using the idea of using Docker containers, which I think some of you tried. I see that I think maybe six or seven people tried Docker container exercises on your own. And you ran into a variety of scenarios. Most of them are very, very expected, nothing out of the ordinary. But I would like to play some of those scenarios with you to get you a little bit more clarity on how does one run something useful, something meaningful, something valuable. And so I want to be able to do that. Maybe some of it is repeat from what we did in the past. Or maybe I should stay focused on an exercise that is written down already here. And so the last time I just gave you a random dynamically generated example. This time what I want to be able to do is actually follow the written steps right here. They are here. Can I ask one quick? Yes, please. You know, thinking back on the previous time when we built our own infrastructure with the two subdomains, our two subnets, one private, one public, and we had the gateway and all this. We would apply, instead of using this docker, we would apply those containers to the private subnet that we have, right? To give them more protection? I would like to repeat your question and make sure that I understand your question. The question that you had was, let me just go back to how it was to begin with. I'm doing that right now. And I would like to understand your question carefully. How would you apply docker containers in the context of running a public and private subnet? Is that what you mean to ask? Right. Like this, we have these three servers that we built that are basically on the public internet. Correct. Yes, yes, you're right. They're on the public internet. And it is not a proper recommended approach to running a large production company deployment. Not. Not at all. This is just a quick and dirty solution to implement something to demonstrate a point. Right. This is not how you do it in real life. You know, if you're a large company, you want to be inside a private subnet. You want to use pretty much like what we did in the other examples in the previous segment on virtual private cloud, where what you would do is something like this. You would say that I have a NAT device here. So this is my NAT box. Here is another NAT box I have. Two NAT boxes. Both of them are public in the A and this is public in E availability zone. So two different availability zones, A and E. These are two public subnets that I have here. I have a NAT box here and a NAT box here to fail over. And these boxes I should get rid of. They're not needed. So here we go. And now whenever I want to deploy containers, I will actually create like in our example, we will have something like this. Three boxes, one, two, and three. These will be the ones that will run days. And you will configure these things to run in a fashion that uses an external load balancer like here. And these will be your days one, days two, days three. And you can add more if you like. Here. Like that. And that way you can scale out your days deployment and then hide everything in a private subnet. Private subnet. In two different availability zones, A and E, so that they will fail over. That's how you would do it in a larger cloud. DigitalOcean is a developer's cloud. That's how I define it. It's a cloud meant for developers who understand the fact that they are directly on the public internet. So the onus, the burden of securing yourself lies on you. You need to manage your firewall. You need to manage your own protection. You need to manage every single thing. Because those guys are not giving you any support. Not giving you any private cloud cover. Not giving you any protection of security groups. There is no such thing in DigitalOcean. No such thing as VPC. You don't have it. You understand it. You still want to use it because it lets you root access with just one click. By the way, these are faster machines compared to Amazon. A little bit faster for the same price. DigitalOcean is slightly faster and gives you SSD. You may have noticed this when you run it. Exercises will run faster on DigitalOcean compared to other clouds. You will see that yourself. And then I'll let you make your conclusion. But the trade-offs really are about securing and actually not about securing, but instead, the trade-off is in DigitalOcean, you're not getting any extra help from the cloud provider to protect you and you are on your own to protect yourself. And so if you understand security, you can be in the public cloud, on a public subnet, and still be safe because you're protecting yourself to begin with. And you can do that very, very simply by running this thing called UFW. This is called a firewall solution built into Linux. And it is fairly simple to run. Not this, not this. Wrong link, wrong link. Go back. UFW is this uncomplicated firewall. That's what I was talking about. And to use this firewall, it's like three commands. I'll pull them up. Yeah, here. Go back. I want to search my gist for UFW and why is the mouse behaving so bad? UFW, show me. There we go. So that's the command. UFW allow port number 22. You can see it bigger. You have to say UFW allow port number 22, allow port number 80, allow port number 443, and then enable the firewall. That's it. And it will take care of dropping every other packet and basically ignore any attacks on the machine. So you're almost in a scenario where you're ignoring any response. You don't even respond to any request on the network because you're dropping the packets left and right, except these three ports are open. That's how you protect yourself in the simplest fashion. So you allow traffic on 22 for SSH, allow traffic for 80 for HTTP, allow traffic for 443, and these other ports are for other applications. You can selectively open specific ports and lock everything else down. That is your own implementation of a firewall on a Linux box on the public Internet. This is the uncomplicated firewall as you would use if you are running Docker on a public IP address. Here is the link for it. Here is this Slack chat link. You can read that. You can actually test it out if you like. And if you want to play with this firewall implementation, you're welcome. You can actually ask me questions if you like as you play with it. That was UFW. And now I want to make sure that I answer your question, David, and then move on to running this specific exercise. I think many of you have tried and some of you are struggling. I would like to point out the aspects that will make you not struggle too much. Yes, you answered my question. Thank you. Thank you. And so the thing that you struggle with are, okay, we have a timeout process. We have a timeout, so it did not actually work on the 6666. It failed, which is expected. I mean, I don't blame the machines. They are too small to handle such a large load, and so I don't blame it. Let me clean this up. To clean up, I want to go back to today's folder and destroy the infrastructure completely. How do you destroy? You have the original command was to create the infrastructure using apply command. You just remove it and call it destroy. And now take the same command and go to the days folder like here in the days folder. PWD is days, and you type the destroy command and then say, yes, I am sure. Kill it. So it kills the whole thing. And I'm typing mistake. I did not type yes properly, so I should type yes, and it deletes the whole thing. And then you stop getting a bill, basically, because you're relinquishing your resources that you took from this cloud here. And so you're basically freeing up the resources so that your droplets are dead and your bill stops. And three destroyed. I mean, you're done. That concludes that exercise. Now we'll do some Docker. We'll do that in this exercise I would like to follow, and I'd like to point out certain things that people will get stuck on. And that is what I intend to do in this VM. So first thing I notice people are getting stuck on is the fact that you are not inside a proper working folder. You want to build something, but you are not really in the folder where the Docker file is sitting. So in the last time we had this example that I was playing with, build a server example. So let me open that folder again, atom, and then build a server, or rather I should say CD, build a server, and then atom. So it opens up the editor on one half that shows me my Docker file. Okay, mouse. Okay, there we go. And here is my terminal. And the Docker file. The Docker file looks like this. Now the challenges that many of you had was, first thing, you need to have the Docker file name constructed in a specific fashion. That name depends on what is your Docker Hub login. So you go to Docker Hub, dockerhub.com. You have a login here. I have a login called Cloud Genius. So that is the name I choose as a prefix to my image name. You will see that's the reason why I have chosen the name. When I say Docker build, I say dash T, followed by Cloud Genius slash, and then a name I like, a name I like, followed by a very important character, which is the location where Docker file sits. That is indicated by a space, followed by a dot. This dot indicates the location where your Docker file sits, which is the current location where the folder is right now here. That's where Docker file is sitting right there. And so that dot basically is what some of you have missed. When you proceed forward, it builds the image and it gives it a tag. The tag is what you chose. This tag has to match the name you have on Docker Hub. So Docker images. You see that this tag that I assigned has a name I like, as opposed to a name I like. I made a typing mistake there, but whatever. This is the name. And if I push this name, it will get success. If I choose some other name that I don't own, it will fail, even if I have logged in. So make sure to create a Docker Hub account, and then you come here and say Docker login with that name. And when you log in, you can then push like this, Docker push. And then you have to provide the name you have chosen, followed by a name I like. And it will get pushed. If you choose some other name, it will reject because you don't belong in that playground. So Docker Hub has given you a playground to play with or a place for you to push. If you choose some other name, it will not get pushed. If I choose a tag name different from Cloud Genius, it will reject it. That's another issue that people are running into. Another thing that I think people have run into is the idea that there are these examples that basically inside the Docker file, you can accomplish whatever you feel like. In my previous example, which was a whole lot simpler than this complexity, all I did was copy and then some file to this location. Remember that slash location. That's where that some file needs to go. And that some file needs to be created. I don't have it, so I'll create one. I'll rename this as some file. And then in that some file, I will put some content, like some content. This file needs to go inside the Docker image, which is built on top of Ubuntu Precise. And this file will get copied into this location here. You will see that build happen. And I will show you how people are failing. It's because you're using a name that doesn't belong to you. So I will also like to fail right now by choosing a name that doesn't belong to me by saying just Cloud or something, some random name. I generate a tag called some random name and I try to build the build. Hold on. I think did I not change the Docker file or did I not save it? I think I did not save the Docker file. So I'll save it now and then attempt to build some random name image. This will also fail when I push. So right now I have it here with the some random name. I don't own that name, so it will fail when I push. Docker push that random name. Sorry, sorry, sorry, sorry. Docker push some random name I like and I try to push. It will attempt to push and fail. Access denied because you don't own that name. This namespace is not yours. My namespace name is CloudGenius. Your name will be different. Other people have attempted the same exercise, Docker, and succeeded. Good. The most important thing that I like is that many of you are actually trying exercises, which makes me super happy. I really want you to try. I really want you to practice. That's the whole purpose of the bootcamp. It is not an exam at the end. We don't have it. We are finishing up one module, but there is no exam because we don't want to have those silly exams, but that doesn't mean that I don't want you to practice. I actually want to do that, make sure that you are actually playing with it, understanding it, and ask questions, which many of you have done, and therefore I want to thank you. I think I want to remind you that in the next time we will switch topics a little bit, and I will talk about this thing called the goal a little bit. I would like you to read that book, please. If you haven't read that book, I would like you to at least read this summary, which is available here in the My Account section. There is a summary section here on the next topic of DevOps principles and practice. There is a book summary available in module number two, unit number three. That book summary is what I think you should read, if not the whole book. It's just one page, one long page, I would say. Chapter by chapter summary is provided. At least read this. That's my request. This will help us in beginning our new topic, new discussion, which will extend the idea that we have in a direction which will basically begin from the core idea that I mentioned here, which is just enough operating system. We will always begin from this point onwards and systematically add exactly the things that we want to add and not add any other crap and build something of use to us. We will do that in an automated fashion. We will not only build something, but we will also deploy those things in a cloud of our choice. We will choose our cloud and we will deploy something of use to our customers. We will build that, deploy that in an automated fashion using tools like Chef or Ansible or Docker. That's what our goal will be to play with these tools more. These are, by the way, just tools to help us accomplish the job. The job essentially is not about the tools. The thing that is DevOps is not about tools. It is about people as to how people who are in this part of the house collaborate with people on this part of the house and make things happen for the customer. That's what DevOps essentially is. It's about people, not about Chef, not about GitHub, not about any of the tools. You can collaborate without using any of these things. These are just tools to make that process easy and automated. That's what we will discuss next and we will meet again on Saturday at 8 o'clock Pacific Time, which translates to East Coast Time 11. Is that right, Shiva? I think so. Yes. The timing will be for Saturday. It will be Saturday at 11 in the East Coast, 8 in the Pacific Time Zone, and the date will be 4th of Saturday. That is where we will again convene and resume. With that, I want to thank you for joining all of us. In this session today, we had... Any other questions, Suresh? Yes, please. In a platform as a service providers like this, if you don't have a proper UI, won't that be creating some problems for developers who want to search what services are running there or more of interactive... You're right. Some people might think that not having a UI can be a problem. You're right. However, let me redefine the word UI in a fashion that is non-standard. What I'm going to say is that when you run a command, like say, for example, days create, this is also a UI. It's a part of the user experience. When you run something like this, you are executing something on the remote cloud and you get a response back. It may not be in a browser, it may not be graphical, but it is still a user experience. That's how I redefine the word user experience to include interface with a cloud service on the terminal. You will see I'm going to take a scenario where I'm going to run a cloud service live right now and it is strictly on the terminal here. There we go. I'm just beginning a backup cycle. It is operating on the cloud, on the cloud genius cloud, and initiating a backup cycle right now as we speak. It is my interface to my own cloud service that I have created for myself. Do I have a web browser UI? No. Do I need one? I don't think so. Why? It is easier to operate like this, and also it is cheaper to operate like this because you're not running a web server that saves you CPU cost. When you become comfortable with handling command line, you don't really want a user interface, and that's how developers tend to think, and that's how the definition of a user interface can mean terminal command line as long as the interface itself is clean and meaningful, intuitive. You see what is going on right now on my screen is actually compressing the content and pulling the content down locally on my machine. What we are running right now is an operation that is taking a complete live snapshot of the cloud genius services that we have running. It is happening right now. It will take about two more minutes, and it will basically grab the entire replica of the database, all the files, everything that all of you have done. I have done all the content, comes down, brings down certificates, dump the database, brings everything down in a zip package for me, and post that in a bucket in S3, Amazon S3 so I can have it safe. Then I'm basically done because I'm protecting myself by running a backup cycle, and this is my interface. Is that a good interface? I think so, honestly. I don't need to have a browser UI. Browser UI is meant for human beings, and you get the joke, right? We are not humans anymore. We have probably evolved, I would say, in a fashion. We have become nerds, in a sense. We don't need that browser interface. That's how I think. Maybe I think differently, but you just saw the backup finished. I was just thinking from the perspective of, since I come from a middleware background, where we have the SOA concept and all that stuff, normally, people want to have a utility industry where they search for services and all that stuff, reusable code and what's running. I actually asked this question to today's developers themselves a long while ago. Why do you not have, let me see, I think an email or something, a long while ago I asked this question, why do you not have a browser interface? Let us see where the response from Layz.com was. The developer responded back saying something long while ago. Where is this? Yeah, here. This could not get the cloud web UI working. What am I missing? The response was, when I talked to them, is that we don't have a UI, we don't need it. They elaborated on what their thinking is behind the scenes, is that it is something that in the open source projects, it is also work on their part to build something. This is open source. They don't get money for this. They decide what is most important for them is to get the applications up and running, for which they can cut down all the things that they don't have to work on. That's what they decided to cut. So they don't have a UI. This is just the reason that they have chosen. I tend to agree with that perspective. But again, not everybody does. But you can always go ahead and build your own UI also. Yes, you can. Since the source code is available, you can always build your own UI if you like. This thing has evolved, by the way. Even Daze has evolved. Now there is a next version of Daze that is coming up, which is called Daze Workflow, which gives you a UI because it is based on a product called Kubernetes. And Kubernetes has a UI, so they just use the Kubernetes UI. Kubernetes is an application orchestration platform. We'll talk about that as well in the third segment. A brief overview for it is that it is basically a place where you will run Kubernetes on a bunch of machines, which in turn will run containers under the hood. And you don't have to worry about where your containers are running. The Kubernetes infrastructure will manage your container deployment across a collection of machines for you. So you basically abstract away from managing individual containers to managing a service. You define what service you want and how much capacity should it scale out to, and you let Kubernetes handle that. So it is giving you one level abstraction. What Daze version 2 does is uses Kubernetes, and then they have the UI, so they just use that UI. So they're cutting down their work. This is just one example of implementation that uses not Docker containers directly, but using an orchestration platform called Kubernetes and run Daze on top of that. That's the evolution that they have done here in the Daze workflow, which adds a developer-friendly layer to any Kubernetes cluster. It's a layer on top of Kubernetes, if you like. And this is evolving. These technologies, every day you find something new getting developed. So we'll play with Kubernetes. If you have a machine that has a 4-core CPU and about 16 GB RAM, you can run Kubernetes cluster yourself on that box, pretty much. I have one running right there. You don't see it because I put it on the cameras. But there's a little box which is 16 GB RAM, 4-core, and it is my private Kubernetes running right there, and I can just go and watch it. And that is what I'm experimenting with these days. But the best Kubernetes implementation is available here. This is the best product Kubernetes implementation today because it was designed by Google. So where is Google Console? And here you can get a production Kubernetes deployed already with one click. And so you should, by the way, have an account on this cloud. They give you $300 for free. You should make use of that. And go to your container engine and create a cluster of machines that will automatically run Kubernetes with one click. Click and you get it. That's it. There's not much to it. You choose how many machines you want. You want three, you want more. And here you get to choose how big the machines will be. And you choose the zone you want to be. Choose the machine size, choose the zone, and give it a name and how many you want. And that's it. You get automated, ready to use Kubernetes for you to be able to use. That's the idea behind. Kubernetes as a project was created by Google. And so that project is now open source for about a year or so, more than that maybe. And this is where the source code lives. And it was initially started by Google. Now Red Hat has joined. A bunch of other companies have joined. And it has become big. So let's see if there's a pull request created by me. I think I created a pull request by me. And so my pull requests are here. So I make little changes to Kubernetes itself. And so a couple of them have been accepted in the source code itself. And this is my little contribution into Kubernetes itself. But what we will begin with is not contributing, but using what they have. So we'll do this at a later point right now. We will first begin with Chef, Ansible, and Docker a little bit before we jump on to other complex examples. We will do more examples, by the way. The second segment, which is the DevOps segment, is flooded with exercises, too many of them. And so make sure you don't miss exercises. Make sure you begin doing them already. They have been written. This is a fairly established sequence. It is not new. It is written properly. And you will probably not find issues. But if you do find issues, I'm here. If you find an issue, something that you do not understand in a certain language, I'm here to help you. But the steps are written down fairly elaborately. It is an established sequence. And I think you should proceed in reading, doing your own as you go along. I will follow broadly the same sequence and include newer topics as we go along, like Ansible and Docker, as time comes. Right? Sweet. Thank you. Nilesh, I have a question. Yes, please. Can you switch to that network diagram you had with the load balancer and everything? Yeah. So my question here is, when you put the NAT after the node balancer, shouldn't there be a NAT before the load balancer? OK. So the purpose of the NAT device is to allow your machines to go out. The NAT device does not come into play at all when people outside are interfacing with your services. Sorry. I meant as a firewall. Some kind of firewall blocking. NAT is not firewall. Listen. Listen. NAT is not firewall. So a router will have a firewall. A router will have a NAT. And that router contains NAT. It contains a firewall. It contains a DHCP server. And sometimes a little bit more things. So what we are talking about is just the NAT function, not the firewall function. If you go by a router, like here, like this, these guys will have these three things. NAT, firewall, DHCP server. At least everybody will have these three things. Other routers will have more. But in our example, we're just looking at this one function. This NAT device does not act like a firewall. It does not act like a DHCP server. Just this function. And it doesn't come into play at all when the traffic is coming from outside. So let's say. Sorry, my question should have been, should we have a firewall in this diagram? And if yes, where? The firewall is already provided to you here. It is called VPC. It has the idea of a security group, which is basically a very granular way of controlling traffic at every individual level. Can this NAT talk to these guys? Yes or no? You can define rules like that. Can these boxes talk to the gateway? Yes or no? This gateway that we have. No, not gateway. This is the load balancer. So every layer, you define a security group, and you put these guys in one security group, and then you decide in a firewall security group rule whether such communication should happen or not. And so at every layer, when you define a collection, a logical collection or a logical grouping, as to what will be together in a security group, you get to dictate who should be allowed to talk to who others. And you can see that in the examples that I have drawn, and I'll draw again, is the idea here. You say, I have my application security group, and this group has these boxes included. I have my NAT security group, in which I have these two boxes included. I have my load balancer security group, in which I have the load balancer included. This is my database. So I have my database security group. And I want to allow people or other machines in the application security group, let them talk to the database. Yes. Do I want to allow my NAT to talk to the database? No. Do I want to allow my load balancer to talk to the database? No. Do I want to allow my load balancer to talk to NAT? No. Do I allow my load balancer to talk to the application servers? Yes. Do I allow people to talk to the load balancer? Yes. Do I allow people to talk to my applications directly? No. Do I allow random people on the Internet to connect to my NAT? No. Do I allow myself to connect to the NAT? Yes. You are basically granular in defining your rules around your security, item by item. That is the firewall. In addition to this, you can also add the UFW firewall at a box level, at every box, which complicates for no reason. There is no reason, practically speaking, to implement the UFW inside a VPC. You don't need to. But in a naked cloud, like DigitalOcean, I call it naked because you are in the public and you don't have clothing unless you put clothing. So this is clothing for you. Otherwise, you are naked in public, which is bad. I should say that. No. That is some country, I should say. So, you get the point, right? You understand that the NAT device doesn't actually play a role in your firewall. Now, repeat your question. Ask your question again. Yeah, I think I understood it. I was not looking at VPC as an alternative to firewall. Okay, no problem. I understand. But I hope this brings clarity to security group discussion. I hope it does. Yeah, it definitely does. This is where the base of the structure is. Once you have drawn all this and put your routes, then we can start building things. I mean, the scary thing is when we get excited to start building the servers and building the securities without thinking about what should be connected. You're right. It's always better to sit back once, draw it. Yeah. I just sent another chat message. I found the site which actually lets you create AWS network diagrams. And also, my guess is they also will tell you pricing. And I think that is called a cloud something. I'm forgetting the name. CloudCraft. CloudCraft. Yeah, it's a good website, cloudcraft.co. And so this website does let you do things. So let's go log in. And I have not set up an account here quite completely yet, but there is an account that I have. So I'll sign in and it will basically let you draw whatever you feel like. And then this is an illustration, but this is not just an illustration. It actually can be implemented in the Amazon Cloud by click of a button. That's the claim, I think. And here you can decide that, you know, I want this machine to be laid out differently. You can basically redraw your diagrams as you like and connect to... If this is your design, you can go live. You can go live with your design. It'll estimate the cost for you and you add AWS credentials. You pay them $49 per month. It will hook up your Amazon account and create this infrastructure for you in your Amazon account. That's the promise. Now, I haven't actually played with it, but I don't doubt that it will absolutely work. The way they have done it, it will work out just like they're claiming, but I had never tried it. It is a good solution, looks like a good solution. And you can create your own blueprints pretty much like design and delete everything you have here. Begin with a clean slate and start new blueprint. You can basically begin with an EC2 server. And here you have mounted here, M3 medium. You can create a availability zone that you define and another availability zone you define here. Two availability zones, you can have two machines in there. In two availability zones, you can add some load balancer in front like this, and you can wire them up. And you can basically do the same conceptually like I'm doing in this piece of illustration, the diagram that I use. It's a separate software, whereas this is a web service. So you can draw the illustrations and then you can go live with it. And when you do, you have to provide an Amazon account. You pay the money, you connect with Amazon and you go live. That's the idea. It's a good service. I've never tried it, by the way, but it sounds like a good service. No doubt about it. That's this cloud craft. This is what I like, I do it by hand so that I understand what's going on. But again, if you want to automate, I would prefer Terraform. Terraform will allow you to specify the detail in simple text files, just like what Deyes did. Deyes had a way of writing code as to how you want that infrastructure to be designed. And... what we did in the Deyes example was basically use that source code that we had here somewhere. And let's go there. Let's go read that. So here Deyes and go to the source code. Where is the source code? GitHub. github.com slash Deyes slash Deyes. And here in the contribution, DigitalOcean folder, this is the file you have to create. It says, create resources in form of DigitalOcean droplets, how many you want, which image you use, which region you want, which size you want, and you want backups or not, IPv6 or not, and like that. So you start with that. How many you want, and you want backups or not, IPv6 or not, and like that. So you specify it in this fashion, in a file, and then play Terraform apply. And when you apply, it will build this infrastructure in your cloud, and you're done. Right? This is the approach I prefer, because you can then control what you want in your files, and you can play that scenario, that will make it happen for you. And you can see similar examples in other clouds in the contribution folder. In Amazon Web Services, you can see that there is this... Where is that? The apply function should be this one, I guess. Okay. So this piece of code will actually create AWS stack using a slightly different tool called CloudFormation. So we'll talk about this also later in terms of how this applies, and we will have an example that we will play in the Amazon Cloud to use CloudFormation to create any architecture that we decide, like this, using an Amazon-specific tool called CloudFormation that is unique to Amazon, and we'll use the Terraform tool, which is agnostic to any cloud. So this is the one I prefer because it is neutral. This is tied to, married to Amazon Web Services. It only works with Amazon. I prefer this because it is neutral. Neutral. Question, does AWS provide some kind of service with networking diagrams? Networking? Like, just click this diagram, does AWS... Diagrams, yeah, I think so. I think it does. AWS itself will also provide these tools. Let's go see them. I think they have a tool called... Let's go log in and find out. I never use that tool either, but we'll figure it out. It's not that difficult. So let's go, go to CloudFormation and you will see these things. So here is our CloudFormation tool. And you can see that you can actually illustrate and create a new stack. Like this. Hold on, stack, design template. And that is where you can design. So here, you can begin designing something like a EC2 machine, get a instance, and then have one more instance and get a gateway. And get a gateway or, you know... Where is the load balancer? Load balancer, load balancer. Auto scaling. No, where is load balancer? Let's see. EC2. Networking? Yeah, I think I'll go networking next. Load balancing here. So there's a load balancer and you can then hook up these guys like this and wire them up. And then you should be able to validate the template. And the template is valid, then it will allow you to deploy. So you should be able to create stack by clicking this button and it will create that stack for you. So it is similar in concept to Cloudcraft, except Cloudcraft is nice looking, this is not as nice. But this is just, you know, this is what I don't prefer user interface, graphical user interfaces. I don't prefer them personally, but it's a choice available. You can play around like this if you are a visual person. I prefer command line and text files, plain text files, much better. You can put these things in a Git repository and share it around very, very easily with other people. It is hard to share this diagram with other people. If you write that code in form of a plain text file and put that in a Git commit and push it on GitHub, you can give it to your team members. They can reproduce the same thing if they all follow the same methods. This one is hard. So this will not translate to anything which can be pushed through the AWS command line interface? I think they have a method of download. So you can download this new designer and it will let you save that picture probably in form of a JPEG, a PNG file. So here we have a picture and you can send this. Or maybe they have another method to actually share with other people. Let's see, we have a save in save, so you can save it in a bucket. That way you can give. You can save that in a local file, call it new.template, you save it. And now this file comes down, save it, and that becomes a template file. Let's open that file in a editor. Here we go. We are going to open that file in an editor to see what it contains. And it contains the code. Here you can see that it is a template formation. It has used the CloudFormation Designer tool to create that. It has basically geometric illustrations of the X file positions of the items that you want to put. And the item will be an EC2 instance and another instance and a gateway and a load balancer. That's what it wrote down in form of a JSON file. This is a JSON file, by the way, as you know, JSON, JavaScript Object Notation. And that is what this file is, is what you can share with your friends if you like. That's one way to do it. But you can't actually execute this as code to create your instance, right? You can, you can, you can actually use CloudFormation to execute the tool. Yes, you should be, and I can confirm that. Hold on. I can confirm that you can import. Yes, you can. So you can just open a local file and load that same file that you downloaded called new.template and open it up. Open it up and now you can execute. So just like save JSON, you can import JSON and execute from here, from this interface. It should be possible. Yes. They also have a command line tool to do the same by the AWS CLI. Yes. That also works the same way. Okay. More questions? Oh, no questions. Thanks, Nilesh. You're welcome. I'll see you guys Saturday morning. See you Saturday. Thanks. Bye-bye.