Hey, guys. Hello, Diego. How are you doing? Hey, Diego, can you hear me? Yes, I can. Okay, good. Your voice is very low. I don't know what's the problem with either my speaker or your microphone or something like that, but the audio is very low. Can you check your microphone? I'll speak something again. Hello, Dennis. Hey there, how are you doing? I'm okay. Good, good. Thank you. Good to see you guys. We just got started in a few as well as little designs. We have four people right now. So Ram just joined. Hi. Hi, Nilesh. How are you doing? Good. Good, good. So on the last time we tried to cover this thing using Heroku, if you remember. And that version of Rails that I was using, the Rails version, was released about last month. We released this version. And our setup that we had all along was version 4.0. Or 4.x, I should say. So the lessons and the exercise and the setup and everything was designed for this version. Whereas the last time that I started trying, it automatically brought down this version of Rails, which caused some trouble, like setup issues. And the setup issues basically came from the fact that we were not ready for this new version of Rails. So what we have done, the last time I discussed that I will create a new machine or maybe an existing machine and focus the exercise on making sure that it works for you. And so I ran that exercise myself. And in the process, what I ended up doing is updating the exercise itself to make it work correctly with version 5. And so that's what I have in here is that in the exercise, I have modified the whole content. And wherever it's needed to make it work correctly with version 5 or version 4, whatever, it will work with both. But the writeup that we have right now, it has been revised to specifically call out this version. And also included updates for Postgres, the pggem, and things of that nature. So they will all automatically get installed correctly. We have to make sure that you follow these instructions, which are already updated on the website. The dependencies that are required are Postgres database itself, a Postgres role, and a Postgres DB need to be created. And then you need to have some dependencies installed. The pggem needs to get installed. And then it moves along just fine. So if you follow that process, you should be able to see this entire exercise complete very quickly. And as a result, you should see something like an application that you create gets deployed on the Heroku platform. So did any of you attempt to run this on your own or did not have enough time, I guess? Because I think we just had only one day in between the other session and today. So you probably did not have enough time. But if you did, let me know if you did attempt or if you succeed. Did you succeed with the Heroku thing? Do you intend to give the shot tomorrow? Yeah. Okay. So the idea with our Heroku exercise primarily is to get us this perspective, which is to make sure that we understand that we can take any application that we create. This is going to be recreating app, or we take an app from the open source, or we take a commercial application. And then any of these things that we deploy onto some kind of a platform service that gets us an endpoint, endpoint like a result where we can send our customers to this endpoint, and then they get the service that we want to create and deliver through a combination of these types of application sources that we create ourselves or open source or get commercial applications, integrate them, mix and match to produce a service, and this becomes your service endpoint that is scalable. And that is the key to using this service. And here the idea is we don't have to worry about the underlying infrastructure as a service, which can be very complex. And yes, it should not be complex for us, people like us who know how to deal with it. But for people who are just plain developers, it can be a challenge to actually deal with this portion. Because as you saw in the example of Heroku, the value proposition they provide basically is that you cut down on this complexity that is shown here, which is they show you this complex diagram in which you're basically building the application, you focus on building your application, and you don't have to worry about the underlying complexity of the infrastructure to develop some application for yourself. They show you this diagram. I think it's not working for us for some reason, not working right now because of some plugins separately. So I need to maybe disable those plugins. But essentially this slider should move and highlight the value that platforms as a service provide to us. And we also discussed this thing idea. I think it starts working now. Otherwise, you have to deal with this complexity. Otherwise, you just deal with your scenario of developing your application and delivering it to the customers. That's the idea. So the other thing we discussed is that if you create your own platform, that is quite a bit of work. So we will actually, since we want to understand what does it take to build our own platform on top of an existing infrastructure solution, we intend to do this exercise today. And as I said in the last couple of times that the exercise that we want to do is similar to what Boeing Company is doing internally. For example, I know that you are running Cloud Foundry internally, which is from Pivotal, which is a division of EMC Corporation. So this is an open source product that Boeing is running internally, and there is a gigantic team behind it. And you're basically understanding what does it take, and eventually you will decide whether to use it or not. And that eventual decision will come after stabilization and things of that nature. That project is happening already inside your company. Based on that idea, many of prior Boeing employees wanted to have this exercise in a class like this. And so that is the reason why instead of creating a way more elaborate platform like this one, like Cloud Foundry, we chose to do something somewhat similar, somewhat similar, but somewhat simpler. It's a whole lot simpler than what Cloud Foundry can do, but at least gets the concept across. So that's the reason why we started doing this exercise primarily to help us understand what does it take to build our own platform, that our developers can then run applications that we create internally for any app, our app basically, that we run it on our pass and that we are able to get and get it to our customers. And this is what the ultimate goal that we had a couple of sessions ago, a couple of boot camps ago, people asked for this. So we created this exercise primarily for people who are interested in running your own pass. This itself is a challenge and we will have it working. I have tested it yesterday and the day before. And yes, I know it works and we will get it to working today. That exercise step sequence is available right in this section, which is module number 17. And it is only one page, but it is intense. So I would like to begin doing that because it can take a lot of time, especially a lot of detail and understanding nuances as to what does it mean in terms of specifically about DNS related issues, getting the open source software for the platform, running it on some infrastructure, booting it up and some related concepts to make sure that the underlying platform itself is ready to deploy our applications. Then we will get an application and deploy it on our own platform. And then we will scale our app horizontally, like scale out and see how it grows. We'll shrink it and then eventually destroy the whole platform itself to get rid of the exercise. So the end of the exercise, we delete everything we created. And that's the entire flow sequence that I want to follow along. And it requires careful and diligence in terms of execution. So I will do that primarily. And I'm recording this session, which means you will have a copy of this. I think you should very diligently watch and more importantly, ask questions along the way, because I will attempt to explain each and everything as I go along doing it. And this probably is going to be one of the, there is one more, by the way, in the next DevOps segment, we'll have one more intense exercise, but this is one of the intense ones today. It is going to be an intense exercise. So bear with me. Look for concepts to understand. And eventually I would like you to do this. So maybe tomorrow, maybe anytime you find over the weekend, please do this. And that exercise will give you a solid perspective on what does it take to run your own platform as a service. So it is an advanced level depth that is needed to make sure that you comprehend, understand, ask questions, and then do it. So let us begin doing this. We intend to get this platform. It's called Daze. That's the name. It is an open source platform available in the GitHub location right there. So you can click on the button, go to the source code. Here's the source code for it. You have to grab this source code into our machine right here in the workstation that we have here, and we'll use that. So first thing first, grab it. How do you grab? You clone that entire repository that is available on GitHub. So that's the step here. Simply you have to grab it and bring it down. So in our terminal, which is this one, I have already done it like a couple of times. So you can probably see that it is there here. And this Daze folder, I did 28th of September, which is like yesterday. And so I'm going to erase that folder completely first so that I don't cause any confusion. And then I will initiate this process of bringing the entire source code down to our machine right here. So this folder needs to go away first. So I'm going to remove that. And a couple of other things that I also did, which I will, as I go along, I will tell you that I have done it before. So you will see some of those sprinkles left over. I will clean them up as we go along because I have done it multiple times. You will probably see those sprinkles and I will point them out to you as we go ahead. So that folder is now empty, which means that thing is not there anymore. This Daze folder that existed is gone. Now we will bring that entire repository down to our machine. So that thing comes down from this location, which is your GitHub location, which you probably know already. I'm making sure that I have a Slack channel also open. And from here, this Daze location, I will bring the source code down by running the cloning command. And cloning is basically bringing an entire copy, the whole thing, including all its historical changes, commits, prior commits. The entire jungle of commits in that Git repository known as Daze will come down to our machine right here and will sit in the folder called Daze. So that jungle is coming down right now. And as soon as it is done, we will have the jungle ready. This Daze jungle, I mean this Daze repository is now available in our folder. I will go inside that folder first and then open it up in Atom Editor just so we can see what's there in that folder structure. Let's go examine. So in that folder, we have tons and tons and tons of detailed folders. It's a complex piece of application. It's there, available to us now. Source code is available. So we'll just keep it open in the Atom Editor right there. However, you will see that in this location, Daze application, this guy who's one of the main developers there, Matt, he's been coding. And I think he's been coding for quite some time. And in fact, his latest commit is from three days ago. So something he changed. And he changes people like, you know, how many developers there? There are 164 contributors and there are 5,760 at commits. So it's a heavily contributed work. It's a body of work with tons of people contributing constantly. And the last one is from this gentleman and three days ago. So, you know, we don't want to get randomized with people contributing, making changes to our setup. So we want to go to a stable point in time snapshot, which is known as the last good released version. So right now, if you get the clone like we did, it is going to get the three days ago version. This version, last commit is 4 alpha delta echo. And this 4 alpha delta echo is the version that you will see get logged. And you will see this 4 alpha delta echo right there. This was Mr. Matt Borsma merging some pull requests from some other person. And that's the change. This, you know, 4 alpha delta echo is the one that is the latest available as of right now. And how many people can actually merge or commit the code? Is that all 164? 164 is the people who have decided to contribute. So, you know, you and I can, it's open source. So you and I can also contribute. But again, you know, the contributions will come like a pull request. And a pull request may or may not get approved. And so pull request gets approved by the team that decides the core team members behind this particular product, you know, this gentleman and his team members actually decide what gets inside the product, what does not. They let in, they control the gates. People who do that, they're volunteers. They're sponsored by this company called Engine Yard, which, by the way, is another very well-known platform as a service. It's a commercial service. And that's the Engine Yard. It competes with Heroku. So this is also, Engine Yard is like the Rails, the word Rails and Ruby and Engine, and they all come together. That's where this Engine Yard name comes from. But this is also a very good platform as a service available, also runs on top of Amazon infrastructure. So this is the company behind Daze that actually sponsors open source work. And people like this guy work actually for, I don't know where he works for, but he claims to be working for Daze. But Daze is an open source organization. So this is a group that actually manages this. 27 people are the core group that are in that Daze source. They control the source for that Daze software. If you go to daze.com and go back to the source code itself, there are 164 contributors, but the core team is only 27. And so you and I can also contribute. However, the team of 27 people will decide whether our contribution makes sense or not. They'll take it. So these changes keep happening. And I don't want to get randomized. Nobody would like to get randomized by these changes that happened three days ago, five minutes ago, ten days ago. So we go to the last known good stable version. And that is available in the branch with a tag. And the latest, biggest tag number we have is 113. So I want to get that number, which happened actually on August 22. So that's the date on which, again, the same gentleman Matt updated the version to 113. That's the version I want to get. So I will go back to my lesson description. And here what I'm doing is a git checkout, 113. I want to go to that point in time, not the point in time, which is known as right now, but that point in time known as 113. So I will do that in here. I will, in my days folder, say git checkout, 113, right there. So now I am on the head is 03E4, like that. That's the head number, 03E4. You can go and match it with here. And you can say that the 03E4867 is August 22. And that was updated to version 113. And the commit number is 03E04. And that's the one we have here. So we are, indeed, at that release called 113, in synchronization with everybody else on the planet. And that's the version that was released. Anything that comes after that is not yet released. Eventually, it may get released. And so the release train is building towards the next version, maybe 113.4. I don't know what version numbers they might come up with. But the last known good version is 113.3. That's what we checked out. So our source code now here, this one, contains 113.3. And we know that for sure because we checked it out like this. So having done that part, let us install some dependent binaries that are needed to operate on this day's platform that we will create. So you recall in Heroku, we had to install this thing called Heroku Tool Belt. And this tool belt is an application that manages your Heroku deployments as well as the Heroku Cloud. And so this tool belt, which is the application that the Heroku command line, you installed it like this. You basically run this one command to run Heroku Tool Belt on your setup. And so that is very similar to what we intend to do except for days. The tooling is called days control, days CTL. And that's the matching days control version we want to get. And so to get that version, we have to run these steps. So the primary step actually is this one. That's what brings it down. And it says, get me that version. So it will bring down that correct version to manage and control the day's platform, which we are going to deploy ourselves. And the other, create a folder, do this, do that. So previous versions you remove. And then you install this new version, 113.3. And then you make a link and then check the version. So these are the steps that you do. And by the way, I have done these steps multiple times already. So I'll just check the version that I have. And turns out that I have already installed the 113.3 version by doing these steps. And so that's what I have done already. So there is no need for me to do it again. It's just a matter of running these steps to run it one more time and you will get the days control version. 113.3, which is the matching version to what our Git checkout is. So our Git checkout, 113. Days control version, also 113.3. And similarly, there is a days client version also, days client. The days client version has to also match. And the days client is just called days. And so we can check that version of days version for ourselves right here. This days client is different from days control. And both of them, days CTL as well as days, both are at the same version, which is the matching with our checkout of the source folder. So to get this days client library, the binary for days client, you do these steps. Basically, bring it down from the days website. And there's an install script for it. It just installs it inside your folder called tilde slash bin, which is basically the folder that we have here in the bin folder. That's where these guys get installed. You can see them by listing them out. I'm just installing them, these two guys, days and days control. Those two binaries that we have downloaded primarily by this line here and this line here. Download those two binaries. They're sitting in the bin folder, which is this one in the home location. And that's the two versions of binaries, days control as well as days version. Days control version and days version, both of them match the checkout. That's the primary thing you have to make sure that we are done. Next, we have to generate some keys. And so a key pair is basically, you know already, you know this command already. This is the SSH keygen command with some added flags included. And the idea here is to generate a key pair pretty much like we do every time, except we are going to name it differently. We are going to call it days. And so I have generated this key pair combination, the public as well as the private. Those two were created yesterday, September 28, days and days pub. They were created in the home.ssh folder when you run this command. And we can delete the keys and create them again, but that's not the point. The point is that it generates those two keys that you see here in the SSH folder by running this step. That is also a needed step because we use these keys to manage our own platform. We run that platform on a cloud, on some infrastructure cloud. We create a bunch of machines that we get from say Digital Ocean and get key machines by a big size and then throw our platform on top and that creates a platform. The challenge with this particular platform is that you will not have anything to look at like you see here in Heroku website. There is a user interface that you can see and log in and all that. There is no such thing in your base. It is truly a command line platform. In Heroku, you can see the UI and you can do whatever you want. You can at least visualize it. In here, there is no UI. I have created an issue for them to eventually create a UI, but they said, no, we don't want to. I think they have a reason to not create a UI because it's primarily focused on developers who don't need a UI to begin with. That's the design point is that it is focused on developers, so they don't want to spend energy on creating a user interface, and that's understood. Having done this part, we created a keygen, create a key, which is going to be stored in this location,.ssh folder by the name, base, and the comment will be base. You can see the keys. This is the public key I'm going to open, and you can see that the key is right here, and the comment is behind at the end, base. The comment comes from this dash C flag. Now, we generate a fingerprint for this public key. This fingerprint is basically a way to operate and a way to identify your key with DigitalOcean. DigitalOcean has this method of identifying key pairs by not their name, but by their content. To create a short fingerprint that corresponds to the content of the key, I'm going to run this command. This command basically generates a fingerprint for your public key here. Now, I have generated this fingerprint, which is a short representation of this long key file. This fingerprint is actually representing this public key. That's the public key that we have created in the previous step, and we just generated a fingerprint for that same key right there. This fingerprint is going to be useful for us to make use of. I'm going to copy this fingerprint and store it in a file somewhere here on the desktop, say, for example. I'm going to open it in a file, and in there, I will save the fingerprint in, let's say, here. That's my fingerprint that I generated that corresponds to your public key. The public key's name is days.pub. I generated that fingerprint based on this command, which basically looks at the days.pub file and prints out a fingerprint like this. That's the example fingerprint. My fingerprint is slightly different because my key is different. It's basically going to be unique. The key is the public key here, and you generate a fingerprint like this command to produce this output, and you want to save that out safe somewhere in a notepad like this, like I just did right here. We'll assemble these pieces together to generate a long-form command, and then execute that command to operate on the cloud. We don't want to go to DigitalOcean website like here, although I will go right now, and the machine creation process will be automated, and I'll illustrate that quickly. Let me log in there. I think I logged in already. You can create droplets by clicking the button, but that's not the method we will use. We will use automation to illustrate this concept of creating droplets through automation and then configuring it all through automation, which will happen momentarily when we get there, to the point that this fingerprint be generated for a public key, and that is how you identify your public key to DigitalOcean. That's the reason why we create that. If you go back to DigitalOcean Cloud and check your settings and check your security settings like here, and check for your keys, SSH keys, they give you a fingerprint for your key. Since I already uploaded my public key and gave it to them in a previous time, I think yesterday, whenever you give them a public key, add the public key right there, they will produce the same fingerprint like here and show it to you. By the way, this fingerprint matches what I generated right there. 0 echo 00 ending with brother brother echo echo alpha. This fingerprint basically matches brother brother echo alpha. That fingerprint is the way for DigitalOcean to identify my public key, which I can call it by name, but then fingerprint is a succinct unique method of matching a key with its fingerprint. It's like the identifier, it's like social security number, for example. Fingerprint, we generated that, we kept it safe here. It is also available, by the way, in the DigitalOcean SSH key. You can see the fingerprint right there. However, that is the hash of the public key that we intend to use. We'll use that in a subsequent step. I have saved it in this notepad on the side and I will proceed forward. What I want to do next is somehow make sure that I provide this public key, not this, let me minimize it. This public key, this one needs to go to DigitalOcean. I'll copy this, go to DigitalOcean, add the key like this. Once I add it, I have to give it a name. I'll call it days and add the key. Since I have added the exact key already, I'll label it already added yesterday. If I add it again, it will say, you already have this key. That's the logic. I'm going to basically delete that key, if you like, and say, now I don't have that key anymore. I can now add the key and it will add comfortably. I'll say days and add the key. It will generate a fingerprint right there for me. It matches the fingerprint I have generated locally. They're basically running the same command, which is this command to generate a fingerprint. That fingerprint is what we have, which is this line here matches that blue line on the left side. That's about fingerprints and giving your public key SSH key to this company, the platform company. Sorry, this is the infrastructure company called DigitalOcean. Having done that part, let us do the next step, which is we want to somehow get a token from DigitalOcean so that we can operate on the cloud without having to type passwords. If you remember, you need to have a password to access the website here for DigitalOcean. Similarly, in other clouds, in Amazon, if you remember, there is this method of getting an access key and a secret access key. Let me get to that point where I will point out exactly what I'm talking about. Here is the token for copy, paste. It will let me in. If you remember, in Amazon, there is this method of generating a user profile and create a new user to generate something known as security credentials. You have an access key ID and a secret access key. That combination that you see right now here and here, these are the credentials to go and operate on the Amazon cloud. If you lose them, you actually may lose money big time because somebody will steal this information and misuse it. That's the token. Similar to this is what we have here in DigitalOcean, and it is called a token. They don't call it the access key or secret key. They don't have two things, they just have one long thing. That one long thing is available in the API section right there, API. Here, you can generate a personal access token. You can just click on it, say click, and give it a name, give it some name, and then generate. That's it. The token gets generated. It's called give it some name in my example. The token actually is this long string. I'm going to copy it, this long thing. That is a way for me to go operate on the DigitalOcean cloud without having to type passwords because it is a token that substitutes. It's like the passport to enter the country, if you will. It's the ability or credential for you to go and operate on API calls. That is the token you need. I am going to use not this token, but the other token that I have created yesterday. I want to use that one. It's the same thing. You can use any token you like, but since I don't need two tokens, I'm going to delete this token that I just created and basically get rid of this token. There is no need for two tokens. I'm going to delete that second token, which I just created, which I don't need to use because I already have a token called days token yesterday created, two days ago, day before yesterday. That token I have kept somewhere in my notepad in here, by the way. If I lose this token, somebody will potentially misuse my DigitalOcean account and start machines, do whatever they like on my dollar. I don't want that to happen. That's the reason why you want to keep these tokens really, really, really safe. Don't lose them. Don't share them. In fact, since my videos go on YouTube, I will delete that token as soon as this session finishes. As soon as we hang up on this conference, I will go back and delete that token because it is going to be on YouTube. Right now, we are recording. I want to make sure that I delete that token and I will remember, but please, you also remember to not share your token with anybody. I'm repeating that. Do not share your personal access tokens with anybody whatsoever. Good. Having done that, that token might look like this that you have here and my token looks like that. I kept it safe and I'm basically trying to assemble this long, complex-looking command. The complex-looking command is what I'm trying to assemble, put things together. I'll talk more about this in just a minute, but you got the token, you got the fingerprint. I'm assembling things needed to construct that longish command. I want to run through an API call that will basically start machines for me and then we'll follow along the steps to install our platform. Then have our own platform as a service running in some infrastructure somewhere in the Cloud. That's the goal. Now, let's keep going. If you have any questions at this moment or any moment, just feel free to stop me, ask me anytime. Our goal essentially is to construct a bunch of machines on which we will then deploy our platform. We will have more than one machine, by the way, which means if you have this machine, sorry, this machine and this machine and this machine like that, there is no way for this machine to know that you have this machine A for it to find out that this B and machine C also belongs to you. You have to have a way of discovering your other machines. Discover my other machines. When you create one machine, it has no idea whether you have this or this also. You have to have a discovery method. These guys need to discover each other, that we are buddies. We are going to operate together in form of a cluster. This is within the droplet? Yes. You can call it them droplet or you can call them Amazon instances or you can call them Azure cloud. The same thing applies anywhere. Okay, so they're independent though, instances. You're not discovering machines within an instance. Correct. An instance is a machine is the same thing basically. Some companies use the word instance. Some companies will use the word machine. Some other companies will use the word droplet. Some other companies will use the machine, virtual machine. They all basically mean the same thing. They are all VMs. When you have some random cloud and you want to create multiple virtual machines, multiple droplet, multiple whatever, it's basically a box. You create three boxes, one, two, three, A, B, C. Box number B will have no idea where is A, what is B, what is A, what is C. This guy will not know that these two exist or you will have more. Who knows? You don't know how many machines you want or create. You'll grow and shrink as you need. They need to be a method, a systematic method for us, for these machines to discover their brother and their sisters, brothers and sisters. Who is on our family because these machines will collectively together form like a cluster and you will actually install your platform on top of these machines together. Like a common situation where you deploy some application, you get one machine, you throw your app on top, and then the app runs. That's a commonly mainstream understood scenario. In our example, we are dealing with a bunch of machines, bunch of boxes, bunch of instances, droplets, whatever, but it's basically a box running some OS. That box needs to know who are the other boxes that need to be participating together for them to discover each other. Hey, we are family. We belong to the same group. We operate as a cluster. That cluster is what I'm really trying to create. For that discovery to happen, we have to use a method. That method is called discovery URL creation. This service for that, it's called HCD. This HCD service is from another open source product from CoreOS. This service is what I'm going to use to basically discover, have the machines discover their brothers, their sisters. That discovery happens through a discovery URL. We need to create one URL using ETCD, this service. By the way, these machines that we need to create, they will be running an operating system known as CoreOS. This is a new, just enough operating system designed to run Docker. The primary purpose of this operating system is just to get to the basic core that is needed to get Docker to work and nothing else. It does not have all the bells and whistles that you would expect from an operating system because it doesn't have any, because there is no need for it. Just a bare minimum to run Docker is what CoreOS provides. That is the CoreOS operating system. It is an open source project for Linux containers. It is an operating system by itself. It doesn't give you input and all the fancy things you would expect from an operating system at all, but just the bare minimum for you to run Linux containers. That's what this operating system is, and that is what we will actually install on our boxes. What's this difference with Docker? Sorry? What's the CoreOS difference with Docker? CoreOS is the underlying operating system that will help us run Linux containers like Docker. Think of it as Linux. CoreOS is Linux. CoreOS equals Linux. Think of it like that. It is like Ubuntu Linux or CentOS. That's pretty much like this, except Ubuntu and CentOS are heavy. This is just the bare minimum, just enough operating system to get Linux containers to work. Then they discover each other and operate together as a cluster. You can have hundreds and thousands of these CoreOS machines operate collectively together in form of a large cluster of machines, on top of which you will throw your platform as a service. Then you have a gigantic pool of resources on which you can just deploy applications and get endpoints available and give it to your customers. They will run your services. You can have these scale-out, scale-in. All of that happens almost magically, but not really magic because we are doing it by hand. There is no magic here, but you just have to understand that that's what we are really trying to accomplish, is that we are creating a bunch of boxes, throwing some operating system on top, just the bare minimum OS, like CoreOS, and then using the etcd service to discover each other. This consensus and discovery service, etcd, is what I intend to use in the CoreOS operating system that I will be installing on our bunch of machines that we will create. We'll use three just to begin with, just to understand, because it's an exercise, it's an academic exercise. The command here called make discovery URL is going to essentially generate that discovery URL. We can see that in our source code when the URL generates. We need to go and check the source code here because that is where the URL will actually get sitting somewhere here. You will find it. It shows up right. Give me a second. It will show up here somewhere that you will find it gets created. I need to run that command for you to see that discovery URL getting created, and you will observe it once you run it. What I have done up until now is generated this fingerprint for a public key, obtained a token from the infrastructure company, and we have put them in our note sheet here. We have the token right there, which I'm going to use it in here, like that, and this is the fingerprint, by the way, and the token I'm going to use in that location. That's the token that I have, and I'll do a bunch of other things, but for right now, let us create a discovery URL, which is this command, make discovery URL, so copy that, bring it to our terminal right here, and run it. When I run, it will go to the etcd service, generate a URL, and put that in our source code in here, and I'll show it to you. We are generating the URL. It is going and wrote that it writes the URL into this file. Hey, Neelesh, when I run that command, it says no rule to make target discovery URL. Are you in the right folder? Never mind, because it came out of this folder. You need to be in this folder. Make discovery URL is basically going to create a URL like this one. It's a unique URL just meant for our cluster members in the cluster to discover each other so that they will know, okay, that guy is my buddy, or that guy is also my buddy, so we'll all operate together. That's the idea behind this discovery URL. We just created one, and this URL, that long form, the URL that you see here highlighted, this 486 alpha, ending with two echo echo. That URL beginning from all the way here, HTTPS, discovery, etcdio, and then that unique number is saved in this location, Contrib, CoreOS, user data. Let's go and see that folder, Contrib, CoreOS, user data in our source code. This is the source code right here. We have Contrib, CoreOS, and user data like that. This file contains the discovery URL right here. It was saved inside in the source code, in this file, in the appropriate fashion, basically included with the source so that it knows what to do with it. It has been embedded in the source code at the right location for us through this command, which basically generated a discovery URL from the HTTPS service and has placed it in the right location, in that location. It's going to use the CoreOS operating system, as you know already. That's what I've done, is to allow this discovery to happen. Once the discovery happens, let us assemble a command, another command that will interoperate with just about a bunch of clouds. It's called Terraform. This is another open source product. By the way, it's called Terraform. It is written by a University of Washington graduate four or five years ago. It's a fairly new establishment, a new company, but amazingly popular in that it has this awesome person, Michelle Hashimoto, is from here in our area. He moved on to create this corporation now called HashiCorp, which has created a bunch of open source products. By the way, Vagrant, a very popular one, Packer, Surf, Console, Terraform, and a bunch of others. This person is amazingly writing amazing code, all of it open source, and many, many companies use that product. You should be aware of this guy, smart man. That's the product I will be using. It is open source on GitHub. You can download it. I think it is already installed. I think it is already installed. Terraform enter should show up. You have it already installed on the workstation. This software is probably already there for you. Otherwise, the downloads are available right here. You just download it for the operating system. It is available for a bunch of operating systems like Mac and FreeBSD and Linux and OpenBSD and Windows and Solaris. Just grab the appropriate binary that you like and off you go. It is open source, so you can go to the source code if you like. This one has 657 contributors, 12,943 commits, so even bigger in terms of number of people enjoying the use of this product. It's an amazingly popular product available on this location and GitHub. The documentation, you can read more about it. What you can see is that it is a tool to operate with a bunch of different cloud companies, a bunch of cloud services. All these services you see on the left side, it can operate with including DigitalOcean that we are going to use today. Google Cloud, Azure Cloud, Azure Legacy, OpenStack, Packet Cloud, a bunch of other things. It's a growing list, even VMware. A bunch of different services all you can manage through this consistent interface called Terraform. That is the tool that I intend to use right now. I need to construct a Terraform command for it. It's going to look like this. That's the command. There are certain components that you need to make sure that it exists. The idea behind Terraform is something that I think you should understand. Terraform is basically a method where you define how you think your output should be like. Then you say, Terraform, take this and apply it to my cloud. Go take this and apply the design to my cloud, and Terraform will go and apply that. When you change your design, and you tell that Terraform, I need to change my design, so Terraform will go and run that, apply again, and it will modify your cloud design according to what you define. You say, Terraform, apply. It goes and applies to the cloud of your choice. If you say, Terraform, destroy, it will go and destroy the whole thing. It's basically an orchestrator. You basically define what do I want, and then you say, Terraform, please do that. It does it on the cloud for you. In this command that looks longish and somewhat complex, there are actually just a couple of words. Terraform, apply, and then this is what I want to really apply. Apply the Contrib Digital Ocean design. This Contrib Digital Ocean design is sitting in our source code. It is sitting in the Contrib Digital Ocean location. Contrib Digital Ocean location. That's where it sits. This entire thing, the entire design is already there. We just need to apply it. While applying, use these variables, one, two, three, four, five. I have given five variables. One of them is the token to operate on the Digital Ocean cloud so that we have the privileges to go and operate on the DO cloud. We'll go and keep that window open for us to see this window. We'll go say, no, go take my token, operate on the Digital Ocean cloud, and by the way, use my key that I'm going to give you. Here's the fingerprint for that. Use this fingerprint and go connect with the right keys. By the way, do this in the New York number three region, and prefix all the machines, the names that you will have, all the droplets that you will create. Name them days at the prefix I would like you to use, and memory should be eight gigabytes. You can see that machine sizes you have here. You can create a droplet, and in there, the machine sizes you can get for whatever size. I'm going to select the eight gigabytes machine size, and I will create three of them using this size, $80 per month. Just be careful. Don't leave these machines running, otherwise, you will get hit with a bill, a long one, like $80 times three at least, if you run it for a month. Our goal is to not run these machines perpetually for now, but to learn. We'll maybe run it for a couple of hours, maybe less, maybe more, and then remember to delete them. At the end of this exercise, we'll delete them. Not a big deal. The cost is not going to be too much. I can assure you that there will be some cost, and you probably have a coupon already, so it will take care of that, most likely, unless you are overspending and just wasting time. In that case, it might cost you. I'm just cautioning you with that. You probably have a $10 coupon which is way more than needed for you to run a couple of hours, so no big deal there. That's the machines that we are going to create. Size, eight gigabytes. By default, it creates at least three, and that's the command structure that I have constructed already in that notepad that I have created right there, which is this one. In here, I have the variable number one, which is the token. Variable number two is the SSH key fingerprint. Number three is New York City. Number three, third location in New York, there are three. Prefix days, size, eight GB, and use the folder ContribDigitalOcean, that's where my design is kept for the Terraform to operate and apply. That command, one long line, multi-line command, by the way. The end trailing slash here, this trailing slash, indicates that it is one long multi-line command broken down like this for readability. This is a cautionary note on the multi-line command structure. The caution is that this trailing slash has to be trailing. It means there can be nothing after the slash, not even a space. If you have space after the slash, it will fail. Remember, the slash is supposed to be trailing the line, nothing after the slash, and that is actually accurate when you try to highlight after the slash and nothing highlights on that line. That's what we have in that command. If there are questions on how to construct the command, please ask away. Token, SSH key fingerprint, region, prefix for the naming, and machine size, five things. Go use this design, apply it to DigitalOcean Cloud, and then do that, please, terraform. We'll copy that command, go to here, and make some room, and apply, and say, terraform, please go do this, and enter. It is going to do it now. You'll go and see DigitalOcean, and you will see that it is creating droplet for us, one, two, and three. They're getting created right now, as we see. On the terminal, it is happening, and terraform is working for us to make these three machines what we told in the design for DAESH. The DAESH design says that I need to have three machines, eight GB each, and we told them, go New York City number three and create these three machines, one, two, and three, and give them these names. Go change the world, good to go, let's go to work. The three machines are ready with these three IP addresses. Let's go see here. The response we got back from DAESH was, sorry, from terraform, was that apply completed. Three resources added. Nothing changed, nothing destroyed. And the output, the IP address available to you, your hosts are ready to go, you can continue the following documentation to install and install DAESH. Your hosts are this one IP address, two IP addresses, and three addresses are available to us. So that's what we have here on the user interface also, if you'd like to see that. Now comes the other interesting part, which is regarding DNS. That's I will describe now, which is somewhat tricky, by the way, and that's what I would like to call out, that it is tricky. And so we have constructed three machines. We call them droplets in the cloud, it's a branding thing. We call them droplets, but essentially they are machines. So we constructed them, created them through the terraform software, and now comes DNS. What DNS do we need? So let us understand that part. So when you have to have a platform, like some platform for the service, and you want to create your apps, app number one, app number two, like that, app number 36, like that, you throw these apps on top of your platform. Each of these applications need to be accessible by the customer. The customer will go here and go here, and they need to know where to go for which app. Each endpoint for each application needs to have a name. That name has to be unique. And so you may remember or recall, if you have done the Heroku exercise, or even if you're not, let me just tell you what Heroku does. So Heroku will come up with some random naming for every application you will deploy, like FunkyRamanujan. This is the name of a scientist, Ramanujan, and he made Funky. And so that's the name they will come up with, and.herokuapp.com. That's the URL they will assign to any application that you deploy, and that will get randomly assigned some name. And these days, since it is gaining immense popularity, lots and lots of people are actually creating applications on Heroku. So they have expanded this logic to say that laughing underscore Buddha, underscore 10356.herokuapp.com. So that's just a naming, numbering scheme that they have come up with, and all of these things are random. This is also random. This is also random. So randomlygeneratednames.sumdomain.com. That's how they are randomly generating endpoints. So that's the platform that we will have. So we will also have to have similar methods, application number one, application number two. Like that, we will add applications here. And each of these applications need to have a unique endpoint represented so that our customers can use it. So they have to have these applications uniquely accessible by three different endpoints, and we need to create them. So Heroku, sorry, these days will help us do that, provided we give this guy a placeholder domain, a placeholder, like asterisk, dot sumdomain. It has to have a generic wildcard placeholder. This wildcard is important because you can have any number of applications here, A5, A6, A37, like that. And so the idea is this has to be a wildcard DNS. Without this wildcard DNS, it will not be able to consistently name and generate randomly generated endpoints for your applications. So app number one, app number two, app number 37. Each of these applications need to be generated some random character here and then be associated with your sumdomain.com. And so that scenario is what we are really trying to accomplish. This can be accomplished by creating a custom wildcard DNS. I am going to choose the cloud genius domains, which is what I have access to right now. However, this cloud genius domain is occupied with a bunch of things running already right now, and I do not want to disturb that. So what I'm doing is going to create a subdomain like this and then creating a wildcard DNS for the subdomain. I'm doing this because this portion is not occupied. Hello, it's not taken. But I don't want to put wildcard right here. If I put that, then my websites and services all will go down. I don't want that to happen. So I'm basically hopping one step towards the other side and creating a subdomain like this for my domain. And I will do that specifically by creating a new name server. New name server for the subdomain that I intend to choose, which is this one, which is not taken right now. So this is the subdomain that I want to use, and I want to create a wildcard for that, for which I need a new name server. So since my main domain is already, it already has an existing name server. And this is the critical part that I would like you to really understand what the most complex part of the exercise is right now. What I'm really doing is this existing name server that we have already, it is in Cloudflare, as you may have seen or remember. Cloudflare is where I manage my DNS for the primary domain. I am creating a subdomain, and I will manage my records for that subdomain in a separate location without disturbing my existing setup, and therefore I need a new name server. So I'm going to create a name server entry in my Cloudflare. For this name, what I'll do is basically create a hello entry for my CloudGenius domain in Cloudflare. Cloudflare is a DNS server that I currently use for this domain. So I'm creating a new name server entry. But just making an entry, I need to know what to put there. And what to put there will be given to me by the new name server. So the new name server will provide me that information. And I will choose to go for my, sorry, I already have chosen for this domain, I have chosen my name server to be Cloudflare. For this subdomain that I'm intending to create and use, I need a name server, I will choose some good reputed name server different from what I currently have because it's a separate new name server. So I can choose Amazon Route 53 or Google Cloud DNS or a bunch of other services, very well-known services available. So my choice today is going to be Google DNS, Google Cloud DNS. And that is going to be new. And so it's a new name server, which means I'll do exactly that. I'll go here, open a new tab, go to cloud.google.com, and there I will create a new name server. Log in, go to console, and then look at my little, what's called, it's called a sandwich, I think. What's the name of this thing? The three lines. So click on that and scroll down to networking, and here you will find Cloud DNS. I do not have anything here, no zones, so no DNS zones here. So I will create one, and I will create Hello Cloud Genius. And the domain name for that will be hello.cloudgenie.us. And that's the subdomain I want to host in this name server. It's just a name. You can use it whatever. You can call it whatever you like. That's not relevant. This is relevant. This is important. Hello.cloudgenie.us is the subdomain I want to have a name server for, so that's what I put right there, and I create one. As soon as I create one, it tells me, go to your main domain and put these lines for name server and start up authority. And so we will go here, put these four lines into my main domain and the main name server for the primary domain, which is just this portion, which is not the hello, which is a service from Cloudflare. I will go there and log in, and once I log in, I should be able to go to my DNS control panel, and there I will go look for hello. And here I will create four name server entries, like what Google is telling me to. Google is telling me that I should create four name server entries, like nscloude1, nscloude2, googledomains.com, like that. So I have created these four name server entries, which are basically managed by the same thing like Google is telling me. So I'll just make it a little smaller so you can see it properly. There we go. So this is also a little smaller. So Google tells me that I need to have a name server record for hello.clouduni.us, put four lines like this, this, this, and this. I did that. I created ns lines, name server lines for hello, hello, hello, hello four times, and this name, nscloude1, googledomains.com, nscloude2, e3, e4. And that's the name server references I have included. So what I just did, let me draw it out for you. What I just did was that I went to Cloudflare and also went to Google DNS and said, you know what, give me some hello.clouduni.us. I want to use that as a name with you. So give me some name servers, please. And so Google says, OK, one, two, three, four, take these from here as name server entries for hello.clouduni.us. And so now I have these one, two, three, four entries here. And that's the only thing I need to do on this primary name server. After having incorporated this as name server entries, name server one, two, three, four, I now have the ability to manage this separate DNS in a separate name server provided by Google. So I can basically forget this side. I can just forget because I'm done with Cloudflare. I don't want to worry. I don't want to disturb my primary setup. I will mess around with this domain, which is a subdomain actually of this domain, the primary domain being clouduni.us. And this hello. is a subdomain, which is now going to be treated as a separate independent domain because of these four records that map to the Google servers. That is the DNS for name server part. Now comes the other interesting part. So now we have DNS records created for Google Cloud right there. And now we will add some more records. The records that we want to add are basically these machines. We want to have these machines, A, B, and C, three machines, one, two, and three. They will all need to point to the wildcard DNS. This wildcard basically is what I want to create for my hello.clouduni.us but with an asterisk right there. This wildcard DNS I need to create. And I can now do that with the new DNS server I have, which is available to me in here. It is called whatever this is not important zone. And that name, inside that name, I have these four name server entries, which also relate back to my original name server, which is the cloud front, which is the primary domain that I have. I have these name servers referencing these entries, which means I can now close out on the cloud front scenario and focus on my new name server, which will help me manage my subdomain hello. And in there, I will create a wildcard entry and put these three machines now I have, these one, two, and three. So I'm going to create a record and put the wildcard right there, the asterisk right there. I put that asterisk right here. And in there, I will create a record type, A, and add one more item and one more item, the three units that I have here. I'm going to copy from here, number one, so copy, number two, copy, and number three, copy. And so now I have these three IP addresses all mapping to a common wildcard domain. That is what I'm really doing, is basically creating a wildcard DNS and save it. Once I save, I have a new entry here corresponding to the asterisk right there. And that maps to the three IP addresses I got for the three boxes I have from DigitalOcean. Right here, one, two, and three. So what do you want to choose? Please, please, louder. TTL values are five minutes are good enough, 300 seconds. TTL values as low as you can go is a good thing. Most cloud services, most name servers will provide you like two minutes, one minute, depending on one of the capability of the services. Low is a good number to have for right now. For our purposes, in this exercise, having a low TTL is a good one. Using the default is okay. So basically you use the Terra Transform 58 to drop it, right? To drop it that you have. And then right now you're using the DNS to map it to outside, right? Yeah, so IP1, IP2, and IP3. That's the three machines I'm going to say, you know, all these asterisk wildcard entries, they need to point to a collection of these three IP addresses. That's where my applications will eventually run. But before they run, we'll have to insert our platform as a service. And then I can run my application number one, number two, number three, four, five, any number of them. And so these guys will need to have a new unique wildcard based identifier. And that's what I will get. They will all be mapping to the collection of machines that I will have that operate my platform. So that's one of the records that I'll create. There are a few more records that I need to create. And they are individual records for each machine. So I need to create individual records like this. So days one, days two, days three. Individual IP address records in the same way like I did here. In here I'll say days number one. And then create an IP address entry for the machines that I have. So digital ocean again and log in. And then get to the machines, copy the IP addresses. So copy number one and put it right there and create. That's days number one. This is an individual record just for that machine, number one. I'll create two more like that. Add record number two. This is going to be days number two. Remember it is days dash number two. Don't miss the dash. Do not miss the dash. Like here it will say days dash two. It has to be dash. Otherwise some step will fail along the way. So follow along exactly. Don't miss the dashes. Days number two has an IP address right there and you will continue along. Put it right in this box. And you have a new DNS for days number two and you save. Now the third one, which is the last one in the name server record creation. So adding the record. And now we have the third one, which is days number three here. And putting the name there, getting the machine IP address, the real machine that we have created in the IP address entry right there. And we create that. Now we have created a bunch of records. And what we now have in short summary, let's go see what the summary looks like. So the summary we have a wildcard DNS entry corresponding to all the machines we have in the cluster, which is three, one, two, and three. And an individual error card entry for each of the machines we have, one, two, and three. That's it. That's the entirety of name server creation. And we are going to use this in Google DNS for our example. That completes the DNS part. Now let's proceed forward. Let's proceed forward. So proceeding forward, there is a picture of screenshot of what it will look like in the right of there. And at the end of the exercise, we'll have to do some testing whether the DNS correctly works or not. So we can go back to our, let's see, we'll put it back here and go back to our writeup. Where is that here? Okay, one, two, three, and four. So I'm going to go back to writeup and begin testing the DNS, whether the DNS works correctly or not. The test method is here. You have to basically copy that line one at a time, bring it here, make some room. Making a room is basically pressing control L to make room. And then type this line, and it will go connect and test connection between your workstation in that folder. SSH connection to core at base number one. The score is the login username for CoreOS. Base number one is the machine name that we have chosen to assign a static A record for that. And then we'll say, you know, give me the host name. So identify who you are. We think you are base one. Please identify who you are. That's the idea here. To identify and test the connection, are we connecting to the right machine? Yes or no? And so that's what we are testing and validating. We should get a response that says base number one as a result of this command. So it will go connect. You know what? We have a host verification fail. This verification fails primarily because I have run the exercise multiple times. And you can get rid of this error by removing this file. RM minus RF, known host entries. So you have to remove your known host entries to get rid of that error. I have done this multiple times with the same name. I am now connecting to a different machine. So it is causing a conflict. So possible DNS spoofing detected. Remote host identification has changed. The last time I ran this, the same command, it was a different IP address. This time it is a new one. And that's the conflict. It detected that conflict and host key verification failed. So I'm removing all the host keys known to me. And now the failure should go away. And it said, OK, I want to connect to this machine. Do you want to go forward? And I say, yes. And so it says, OK, day is number one. That's the response. You got back from the command was to get me the host name. The answer is day is number one. Good. We repeat the same command. We will not get prompted, but just get the answer right away. And here it is, day is number one. You got that. I'll repeat the two for the other two machines that we have. So repeating the same step, step number for machine number two. And yes, I know what I'm doing. Proceed. And the answer is day is number two. That tells me that the DNS setup is correctly connected, properly configured. The DNS changes we made in Google DNS are done correctly. Let's do the last machine in the cluster, which is the third machine number three. And we'll say yes to it. And we will get a response back saying day is number three. So we have now configured our DNS correctly. That's we know. Now we want to enable keyless login. You may have seen that I do not type my keys occasionally when I type in, because I have SSH agent in use, which remembers my key. That's what I'm going to do right now, is to enable keyless login. So I don't have to provide my keys manually. And for that to happen and work correctly, I need to run this evaluation command first, like this. And then I will add my days key, because that's the key I want to use. This days key that I have in my folder here, this key is what I want to use. And so I'll add that key to SSH add. And it added. This SSH add command remembers that I want to use this private key, this one. And I can list them out if I want. And it is using the days private key that I have kept safe in that location in this folder. Now that this SSH enabled keyless login, I don't have to provide a key explicitly. I need to now establish a tunnel. A tunnel is a method for me to just connect into my cluster. So I'm basically using days one as my tunnel into the cluster. And so I'm going to go to that folder. I'm always working in that folder, by the way, days folder, which I'm already there. I'm already in the days folder. So remember that. And then export this reference, because it will tell that I need to use that as my tunnel for days control. So exporting that line in the terminal and then listing out. So let me clear screen first. And then export that line. And then run a list. A list will show us an empty list, because we don't have a platform set up yet. So here is the empty list coming back with unit, machine load, active, and sub. These are empty right now, because we don't have a platform set up quite yet. So having done this part, we should now install and start our platform. Installation of the platform requires these steps. So we'll do one at a time. Installation of the platform using our private key that we have. Enter the whole long command. It will install that platform on. It will configure this, actually. This is the configuration step. Another one is also configuration of the domain that we want to use, which is hello.cloudgini.us. That's the subdomain that I want to use. Actually, it's going to be the domain that I want to use for my platform. So anything.hello.cloudgini.us. That's the names we'll get back from our application that we'll get back. It will be something like this. Anyapp.hello.cloudgini.us. That's the kind of nomenclature we'll get. This AnyApp is basically the wildcard entry we put. And that's the response we will get back. And you're giving the private key versus your public key? Yeah, this is not being passed. It's a configuration set. It's not being transmitted over. So this is just locally kept. Referencing this private key is what I want to use. It is not going there. It is still locally. It is not being copied over. It is still local to your workstation. In the other configuration, we want to tell our DAIS platform that our domain that I want to use is hello.cloudgini.us. That's the domain I want to use, this one. So that configuration step is going to let the DAIS software know that I want to use this domain. And it will understand, OK, you intend to use this domain. And then the wildcard corresponding to that. That wildcard is going to be useful for us in order for us to construct our applications once we deploy them. And on that DAIS install the platform, we are going to install the platform right here. And let us invoke it and let it go. It's going to be basically installing the platform on those three boxes, the cluster that we have created into the Digital Ocean Cloud. And it is doing right now that exact thing, as you can see. It takes about two to three minutes. And once that installation finishes, we will do the next step, which is to start the platform as a service. So it is basically installing a bunch of things right now on those three machines. They will be any number of machines, by the way. They will be parallelly executing multiple things. So I think it has successfully installed the DAIS platform onto our cluster. This succeeded. It tells us that run the platform like this. It says that. It says, please run the DAIS start platform command to boot up DAIS. We haven't started it, but we haven't started it. So we're going to start it. If somehow this step fails for some reason, if it fails, saying you could not find a unit template, blah, blah, blah, run this to refresh units, and then you should be able to proceed with the install step. If the install step fails, if the install fails, you need to refresh units. It did not fail on me. I'm not running the refresh unit step. I will actually start the platform now. And this step takes about 50 to 20 minutes. So just be patient with it. And the DAIS start platform command is what it is telling us to do. DAIS control start platform. We will do exactly that. I'm putting a note on the time right now. It's 6.27. And I will invoke this command and let it run. And we will watch how long it takes. But this is what is actually running the platform on our cluster. I know this step takes about 15 to 20 minutes. So we'll let it run right now at 6.27. We'll talk about other things right now while it goes on the background. So once that running finishes, we will have an active functional platform as a service that we deploy on our own cloud on these machines. That's what we hope. We are hoping that it will finish. And I know it does. So it will finish. And at that time, we should be able to see our platform characteristics and basically log on to that platform or take an application, throw it on the platform, and it will run. It will give back a URL for us to use. URL will look something like, you know, fancyEinstein.hello.cloudgenie.us. So the fancyEinstein, that's the name we will randomly get generated, you know, some some some some ad some adword, adword underscore name of a scientist.hello. So that that's the asterisk, the wildcard that DNS will kick in and will randomly assign these names for us for our application that we will deploy. And we can then visit HTTP colon slash slash that endpoint to see our application that runs on our own platform. This is going to be our own platform. And that's what we are waiting for it to happen. But in the meanwhile, let us talk about couple other things while it does that. So let me quickly check or maybe take a short break right now. And in five minutes, we'll come back and talk about platforms in general, see how other other open source products are doing, see how other corporate companies are doing in terms of platform as a service. And understanding those things while this thing finishes. So break. Yeah. Take a short break right now for coconut water, maybe. So I'll take a short break for five minutes. Six thirty five. We'll let it run. Thank you. Hey, Nilesh. Hi. This is Ram. Hi. So it looks like the Terraform apply command. Let me share my screen. OK, you cannot. I have to disable my sharing first. Oh, yeah. So I'll just talk about it. Give me a second. I'll just get my glasses. Yeah, let me disable my screen sharing so you can share it. Now you can share. Yeah, go ahead. You can hit the green button to share your screen. Yeah. You can see it. You can see it. So it's an illegal, illegal, your key value. So what happened is I had the way how it is in the page. So this is how this was in the page. That was failing because it was complaining that the token is invalid. The way how we are passing the token value is invalid variable. I'll tell you the resolution for this. So I was looking at the tickets on GitHub for that. There's no GitHub ticket for this. The resolution is simple. I'll tell you what the resolution is. What happens is when you copy and paste from a browser to a notepad like this, I don't know if you're using Windows or not. Not Windows. I am using Mac, but I did copy into. What happens is in the copying and pasting process, somewhere along the way, these little quotes that you have, the single quote and double quote, they cause problems. They really are so difficult to identify from your eyes, you cannot tell. My recommendation is to get rid of the single quotes all over the map. Completely delete them by hand. All of them. And then manually type the whole thing. Manually type the whole command without copying and pasting, and it will work. First, remove the whole single quotes all over the map. And then listen to this. Copy the whole thing from this notepad and create a new file with just the copy from Linux to Linux. Got it. OK. And don't add your single quotes right now. Do not add. Do not add. OK. Remove the single quotes, copy this portion, take it to a new notepad, Linux to Linux copy, and then manually insert single quotes. OK. That will work. All right. You got that, right? Yes. It's Unicode. It's Unicode problem. So when you copy, do not copy like this. No, no, no, no. You have to get rid of the single quotes first. OK. Then copy. Go to a new window. I've done it so many times. I know this. Yeah. No, I realize we used to have this problem. This is a classic problem between it's Unicode. Some crazy characters come across sometimes. That's what's going on. OK. Yeah, we did have some problems like this while we had to work with the Vagrant files. I know. It happens all the time. So that's why. Get rid of all the single double quotes, and then copy clean. Go from here to another Unix copy. Go to a new notepad. Go to Atom. Go to open new, file new. It's tricky. Control N. Ah, there, we are still getting used to this Linux at the moment. You want to test it. All right. And now? Now do it manually. Yeah. OK. You got it. I think you got it. I'll do that. Yeah, let me actually take a walk away. I'll come back in a minute. Sure. OK. OK. OK. OK. OK. OK. OK. OK. Yeah, it is still going on as I expected. We started at 6.27, right? It's 37 right now. Still going on. OK. So while it does proceed, I would like to identify a couple of projects, interesting projects happening in the industry that are focused on platform as a service. One of them is this open Cloud Foundry, like I mentioned earlier. Foundry. So this is a fairly elaborate platform as a service. I think you guys are back. I can see most of you are back. Yeah, you are there. Just checking, hey, you are there, right? Anybody? Looks like you're there. Yeah. OK, good. Hey, Nilesh, just so you know, that didn't work as well. So only when I wrapped all the key values and double quotes within the single quotes, then it worked. Then it worked. So single quotes outside, double quotes inside. Yeah, so I was looking at their GitHub. And they do have a ticket where it's in Terraform 7.2. So if the values are starting with numerics, so that's when they have problems is what the- They make it a string out of it, I see. And because, first, if I wrap one, it expects all other variables also to be wrapped. Otherwise, it complements illegal passes. Thank you. I understand what you said. So I know I understand what you said. So yeah, it makes sense to make it a string. So just to clarify, what Ram is saying is something like this. So there is apparently a bug in Terraform. So the Terraform bug looks like this. What Ram has found out is that whenever you say dash bar followed by single string and say, my example. Let's see example. Key name, any key. Token equals a, b, c, d, 1, 2, 3, 4, and a single quote. This will work fine. However, if you have var, single quote token equals 1, 2, 3, 4, a, b, c, d, it will fail because of this numeric beginning. Maybe it's just a minute of practice. So the way to resolve the resolution is this, var, single quote token equals double quote, 1, 2, 3, 4, a, b, c, d, double quote, and then single quote. That's the resolution. That basically converts this numeric into a string. And that double quote here, from here to here, makes it a string, even though the beginning is numeric. And that's the resolution. So thank you, Ram. So the other ideas, in terms of here, this project, by the way, is a very good project. It's from a company called Pivotal, which is a part of EMC, which is a part of Dell. And so all they are basically, it's a gigantic company now called Dell. So that's where this originates from. But it is open source. So what you're looking at is the open source website. There is also a corresponding commercial website called cloudfoundry.com, which is where the commercial products and services are available from the company called Pivotal. And that's where they actually, that's how they make money. Let's put it that way. So they make money on this platform. Let's put it that way, so they make money on this platform called Pivotal.io, which is basically Cloud Foundry implementation. And this is the underlying open source. There is a community, there is source code, and all that is available for us to use. And on GitHub, you can find Cloud Foundry, where in this group, there are a bunch of people that are basically working together to collaborate on creating the Cloud Foundry project. And that is a very good platform solution. And it is so good that many companies like IBM has taken their implementation and created their own platform as a service solution. And they brand it differently. They call it IBM Bluemix. That's an example of what Cloud Foundry has done for IBM to construct their Bluemix platform, which is a commercial platform service offering from IBM that uses Cloud Foundry under the hood. There is another company which is local to us in our area here in the Seattle, Bellevue area. And that company is CenturyLink Cloud. These guys also have created a cloud platform by acquisition of a company that uses underlying platform as a service. They acquired this company called AppFog. AppFog used to be a company, now a part of CenturyLink. And AppFog uses Cloud Foundry at the core. That's what you're looking at here. Now they are part of CenturyLink. But AppFog used to be a good platform. It's still a good platform as such. Now, the use case behind these platforms essentially is to make sure that developers don't have to muck around with infrastructure details. What we are doing right now is actually dealing with infrastructure ourselves, because we are going beyond to run our own platform. By the way, I succeeded in running a platform. So we installed a platform. We started our day's platform. We created a storage subsystem, logging subsystem, control plane, data plane, and a router mesh. And all of that is done. So we should proceed, and we'll have this discussion later on some other day. So the discussion part we can have either offline also or on Slack chat. But let's close out on this discussion and continue on the exercise here, which is to make sure that we use our platform. So now that we have our platform running, we want to be able to make use of it. So here, it says, please set up an administrator account. So we need to do that. And we can simply create that administrator account by following along. But before that administration, we want to run this command one more time just to see what we have. So that command, we want to run here, day's control list. And it will show us what do we have in a bunch of services that we have running. They will all show up. We'll run it one more time, just to see clearly. So in that display that we see, we have a bunch of services running and loaded, active, and running. So these are the services that we have running on those three boxes that we created in the DO Cloud right here. So that's what we saw. And then next step that we have is to use that day's client, which is a different binary. This binary that we have is the day's control binary, CTL. I want to now run the other binary called days, just days, not the days control. So not this, but the other command. So I want to be in here, the days folder, which is where I am already. And then I want to register myself onto my own platform. So this is like first time. I'm using my platform first time. I'm registering myself as a user, as a first user, who is automatically going to become an administrator. So my platform is available at that location. And I will use that command to register myself. So here, please register me as a user. So I'm going to say, my name is Nilesh. And my password is something I will choose. And I will repeat the same password. And I will give my email address. And now it registered Nilesh as a user on the platform, as an administrator user. Now, since we have a platform ready, we want to make sure that we operate on our platform using a key pair. So we will send our public keys to them by running days keys add. It's very similar to Heroku keys add, where we run that command Heroku, take my keys, and add it to your platform. Same thing we are doing here, except we are running a different binary for our own platform, not Heroku, days. So here, days, keys, colon, add, and run it. It says you've got two keys there. Which one do you want to use? So I can use one, or I can use number two. So I have two choices here. One that is specifically used for days, and the one that is generally created for every other use case. So I can use either one. I decide to choose number one. So which one would you like to use with days? And I'll say I want to use the number one key. And then it will take the public key, days.pub, upload it to our own days platform. So it goes to days. Upload it. And then our platform now knows our public key right there. This is the command, send your public keys to days. We did that. Now, instead of writing an app like we did in the Heroku, we actually wrote an app, which is not necessarily the core focus of this exercise. Not about writing an app, but more about running our own platform, and then making use of it. So I'm going to use a ready-made existing application. Then I have it here on a different location. And so since we are done setting up our application, our days platform itself, I don't need to be operating on that folder which contains the source code for the platform itself. I want to come out of that first thing. So here we go. Come out. Somewhere else, outside, in the home location, so cd enter. And there, I will now remember to come out. That is important. Don't mess with that days folder. It is containing the source code of your platform. So don't play in there anymore. You want to now deal with applications. We are not dealing with the platform source code, but creating a separate folder for an example application that is available on GitHub. I have put it a while ago. The example application is available at that link. You can go there. It is publicly accessible. And it looks like this. So it is be a cloud genius example, Ruby Senator. That's the application. We will use that. And we will, first of all, bring that application down. It's a very small, simple application, really tiny. We'll clone it. Clone the whole thing local. So it comes down, and it sits in this folder, Ruby Senator. Example Ruby Senator. That's the name. It will come down. And now we have a new folder called Example Ruby Senator. That came down right now. This time is actually UTC. So not local time, but England, London time. So September 30, London time. So we are going to go in there, Example Ruby Senator. And in that folder, we have the application, which is a Ruby application, as you know already. Ruby and Sinatra-based application, as opposed to Ruby and Rails application like the other time. This is a Sinatra as a different platform. Again, user of the Ruby language, with the Sinatra as the application platform. And we will take this application and send it to our own platform as a service. To send that application over, we need to first check a couple of things. You know this idea of a Git remote. So a Git repository that we now have here. This is the Example Ruby Sinatra app that we have. This one came down from GitHub. Because I brought it down, I toned it. So there is a remote here, a remote connection between GitHub and my folder. This remote connection exists just because of the fact that I cloned it. Now I need to create another remote. And this remote connection has to become between this folder and the day's platform that we are running as a service right now. This connection has to be established, a remote connection. So we can first check how this remote connection is right now by checking our Git remotes. Git remotes-v. And it tells you that there is a remote called origin, which maps to GitHub location for fetching as well as pushing both. That's the number of two remotes we have for fetch and git push. Both point to GitHub, where it came from. Now we will create a placeholder for our application, this example Ruby Sinatra application, to run on the day's platform, our own platform. You want to run our app, this is the app. You want to run this app here. So you want to make room for it. So which room? You want to create that room. And the room creation is day's create. That's pretty much it, day's create. It will create a room for the application to go and sit. And so we create that room. It created a room for us. And we got that room called upbeatzikurat. That's the funky name I was talking about. And the remote is now available. The Git remote was added to the folder already. So we can now check the remote, git remote. And we have four remotes, one called origin for fetching, another origin for pushing. So two remotes for the origin location where it came from, this application came from that location, GitHub. And we have now created another location, another remote called days. These two are the fetch and push remotes that point to the placeholder, the location, and the room that we created. We have this room here. This room, that remote reference goes to that room that we created here by typing days create. And this remote established with our Git repository known as example Ruby Sinatra, which came from this origin and will be going to this location. But we're going to push it to that location, basically. And we can push because we have our keys there. And we can push. And we have the administrative privileges on that platform as a service. So we can push. And so we are now going to push. So git push, days master. Put the master branch, push the master branch into the days remote. That's what this thing is. So git push, days master means push this guy, the master branch of this, so git log. We'll show you the logs. And the master is somewhere here. That's the top level. And that master needs to go to the remote, that remote, this push location here is where it needs to go. So the command is git push, days master. Basically, git push this over to days. And while you're pushing, make sure that you're sending the master branch, the main thing, from our application. So push the master branch from this repository from this repository over to the days remote. So push remote, days, which is this URL, ssh, colon, slash, slash, blah, blah, blah, upbeat, ziggurat.git. That's the location it will be sending the application, pushing the application over. Once I run this command, git push, days master. And I'm going to send. So it says, do you know what you're doing? And I said, yeah, I know. So go do it. So it is pushing the application. It said, I detected a Ruby application, and it runs Ruby 193. And I'm going to install the dependencies for that application. And it's going to do the gem install, bundle install is happening right now on the remote location, which happens to be our own platform. And so you're seeing that installation of the application on the remote location in our platform on those three machines that we have from here. That's where the applications will be running eventually. But on top of these three boxes, we have a platform layer, a platform as a service layer, which is the days platform. And that is where it is running a Ruby on Sinatra application. And that's what we just pushed. So it is doing that and running it. It is building that application image and going to start a bunch of Docker containers and basically give us back a URL, which is what I intend to go and open in a browser. And all of us publicly can see that application because we set to go live. So we are going to go live as soon as this thing finishes. As soon as this operation finishes, we will get a URL back that all of us can visit simultaneously and see the application, which is this example application that I am pushing right now. And as soon as the push finishes and the compile, build, and execute run completes, we should get a URL back from there. It should not take too long. It should like maybe a minute or two. And then we will have a URL back that we should be able to visit and see the application live. It's going to be a very simple application, so it's nothing complex. But at least if you get the point across it, you can build an app, send it over to platform, and it runs. And the commands we are operating on is git push days master. And that's it. It goes live. And let it finish. And then we'll see how it operates. We're going to get stuck. And that's the challenging part. We cannot even see. There is no other way to see how the platform is doing for us, because there is no UI. The only way to go forward with this is to break that and do it again. That's the only user interface we have is the command line. Sorry, say again? Can you have to log into the console? Yes, you can. There are days commands. You can go and log on to the days containers. There are a bunch of Docker containers running on which this service is going to get executed. We can go in and investigate like that on a separate command line, which is what I will do if this doesn't finish soon. I will go on the side and basically grab another terminal and figure out what that thing is doing. So we can alternatively go and inspect what is going on on these machines. For example, are they doing anything? What's the bandwidth consumption? What's the CPU consumption? So here you can tell that the machines at this time, which is about 10, 21 PM between these times, the CPU consumption was heavy. The disk I was also heavy. This is the time we were installing and running the platform. This was on machine number one. Similarly, for other machines, let's go see what machine number two was doing in terms of the access in the characteristics of that machine. And the same time window, you have some activity there, heavy activity on the CPU side. Some disk IO and the same time frame. And the third machine also shows similar. The graphs show that there is some activity here at that same time window. And in the recent future, we have some spikes going there for bandwidth. And I think it is stuck. So I'm going to break it and push it again. And it failed to push some references. Another git push is ongoing aborting. So we can basically create a new application. So we can ignore this. The simplest way to deal with this is if the push fails, we can just go back a step, remove that application completely, and we now have a clean slot. So we can go and bring that new application source code down again. Simple way to deal with the problem. There are better ways, by the way. This is just the simplest one, is to just get rid of it. And then we are going to create another remote. So for example, we'll inspect the remotes right now, which is going to be only one. Only one remote we have. Sorry, we're going to go to the example location first and then examine the remotes. We have only the GitHub location as the origin remote. We are now going to create another app, placeholder. This is the room for the application. We're going to create a room, create some room. We're going to get created Clutch Z Fireball. So Clutch Z Fireball got created, and that becomes a remote available to us in that location. So we'll say git remote, and we now have a days remote. For pushing, we have this URL, Clutch Z Fireball, and we can push our application over there. So git push days master should push this application back to the same platform, but a different room. The same platform, different room, and see how it responds this time in a different room. Maybe that room was broken. We can kill that room separately. This is the easiest way to deal with application deployment problems is just to create a separate room and just go. So let's see how this responds back. On the other window, we should be able to see days apps. So we have two apps there. One of them is Clutch Z Fireball, which is what we are interested in right now. And the upbeat ziggurat that we had, the other app, I think we can delete that one. We can delete that one by simply days destroy, by destroying the other application. How do we kill that? So let's see, days apps, destroy an application. OK. So I think I was being impatient. It is going to take some time for it to do something while it's doing, because I think it was doing something, and I was getting impatient, and I killed it. I shouldn't have. I think that's what it is. Let me see how the kill happens for the other, the one that we don't want. So days apps here, I'm going to kill the upbeat ziggurat. So days destroy. I think this should be the syntax. Let's see, days apps, now, OK, the way it's going to be, days app equals upbeat ziggurat and dash dash confirm. No? What? I'm typing exactly what you're describing. So it says dash dash app, and then the app name, basically, I identify the name for the application, which is what I typed. Did I type this wrong? Maybe I should type it wrong. So days dash a, and then the app name, destroy. No? It doesn't like the destruction. Days commands, arguments. The destroy comes before. Yeah, our own platform. We have to learn how to use our own platform apparently. OK, there we go. So now it says, in order for you to destroy that application, you need to type this. And so what I'm going to try one thing before I destroy is to see whether the application actually went live. It might have gone live. Yes, it is running live. So the other application is, I don't want to kill it. It is actually running live. And so the application is live right there. You can see it. I'm going to paste a link for you. Even the upbeat ziggurat did not. It is pushing image to private registry. That part, I think it is getting stuck for some reason. But the application actually got deployed, both of them. Let us see. So we have days apps. And so we have two apps. Let us construct the URL for them. And I will type them one at a time in our Slack chat. First one is this link. And the second one is going to be the other name. What is the name? Club C Fireball. And so I'm going to copy that name, construct it in the Slack chat right here for you. And you should be able to run these apps and see the map, see these apps running on this two URLs. So first one you saw. It is running in that container ID, 3085, all that. And this is the upbeat ziggurat. Now let us see the other application. Second one seems to be not ready yet. I see. So it is doing something. Maybe the key thing is to be patient with this. And I am the most impatient guy of all you'll find. I just don't know that it's still doing it. It's still doing it. And that's why it is not found, because it's not done loading yet. Thank goodness I did not kill the other app. So the idea behind these apps are still setting up things needed to make it work correctly. And eventually, the app will come live. And it shows you the app is now live and that container ID. And you can keep hitting that app. And all of us can hit at the same time. It will render this experience right there, this exact experience you will see in the application. That's a very, very simple, trivial app, actually. It doesn't do much except say that I am running on the container ID, whatever the ID number is. That's it. Now, having understood this part, let us see if we can scale our applications. So by the way, this thing failed. The pushing image to private registry and then launching. Launching failed to retrieve configuration from controller server error happened. So something went wrong in this deployment on the Cloud C Fireball thing. And what I need to actually do now is to delete the Cloud C Fireball, because that's not really interesting to us. Right? This failed. This other first time we did the build Zivaratti did not fail. Did not. And we want to be able to construct another application that we want to be able to scale. The idea is I want to demonstrate scaling part. So here, the next step, once you have an example pushed, so you pushed GetPushDaysMaster, it generates an application for you. And so for example, in our case here, it failed. So it will not, DaysOpen will not actually open anything in the browser. It will show failure. That's what you're looking at, the failure part, because the app actually failed. However, we will try one more time, another instance. And that one, I hope, will work. If not, we'll have this working app. We'll modify the remotes for that and see if we can get it to work. So the getStatus, let me just quickly check status. Let me see if it's clean. And so I'm just checking the getStatus and identifying getRemotes for it. For the existing broken application that we have, we have these getRemotes. And we want to change them to the other remotes that we have, which is this remote, which I have to manually construct, because I deleted that. So that's not really a good thing to do to manually hack remotes, but you can. You can basically hack the remote for this and include this reference, which is a kludgy way of dealing. A cleaner way of dealing with this problem is to get rid of both the apps and do it one more time. That's a much more cleaner method. Having said that, I'm going to destroy both these apps. So days, destroy. App name is, one of them is kludgyfireball and say kludgyfireball, and it destroys. Next, we'll see how many apps we have. Only one. So this time I'm going to destroy the upbeat ziggurat also. So this one should go away. And so days, destroy, the upbeat ziggurat, and it's gone. After having killed both these, it took a little bit longer time for it to destroy, because it was a functional app. Now we have to remove the example application again, and then clone it one more time. So we get a fresh copy of the application from that location, and then create, go inside there, and days create an application, a room for this application to sit. So we got this time vanity knapsack. That's the name we got. Now we are going to get remote, check the remotes for this, which we should see four remotes. We should see for the vanity knapsack on our own platform. And origin was the GitHub location. With that understood, we are going to get push days master. And this time, I hope it doesn't fail, and hope I remain patient. That's also important. I'm so impatient. And so once this runs, we should be able to have it open like this. So once it will basically open a browser, when you type days open, it opens the browser and shows you the app in the browser. And then we can scale the app like this. Days scale the application to three containers. And don't feel limited. We can scale to 13 containers, and it will still work. And as a result, what you will see is that this application container ID like you saw here, this ID, will show you 13 different IDs as you scale it to 13 different instances. And you just have only three boxes, by the way, here. The boxes may be limited to only three, but it doesn't mean that you cannot run more containers, because these things are running in containers, in Docker containers inside these three boxes. So the application seems to have built successfully. It is going to be pushing to the private registry and then come back with a clean exit, for which I need to remain patient. So I'll stop looking at the screen, otherwise I'll kill it. So let's go hide it. The idea behind scaling is to be able to run these things in multiple different containers and have them respond to users from wherever they are. So people will hit, and every time a user hits, they get presented the same application from a different container. So the same story that I was describing before, these people, they're all visiting your endpoints. And the endpoint can be, in our example, it can be whatever we have here. So let's see what the example that we have. We are going to get this name called, what was the name? We got assigned, the name was Vanity Knapsack. That's the name we got. So we are basically looking at the Vanity Knapsack name. So these people, these customers, are basically hitting the name Vanity Knapsack,.hello, .gd.us, and that's what everybody is visiting. And they all reach one of the boxes that acts as a front end, basically a load balancer that will balance the load among multiple containers. And let us not confuse ourselves with this box representation. So this box representation, I think, is incorrect. We should have a representation that is different. Let me move this aside a little bit. And these guys should go away. This should come back here. And the idea behind this concept essentially is that right now we have three boxes, one, two, and three. And they're actually decent size, meaning they're big boxes, 8 GB each. So they're big. And so we have three of them running in our cloud. We don't have these guys yet. We don't need them right now. But we have a container that is actually a container representation that acts as a load balancer. And these three boxes are Docker hosts. And they are getting managed by Kubernetes. It's another open source project by Google. And these things are used by Days as a platform to construct the Days platform. But that's what you're looking at in this example, which is what we are running, is this thing called Days. If you go read the top line there, the top line is a core OS and Docker-based platform. That's what we are currently using. So under the hood, it is core OS-based. And under that, you will have a bunch of Docker containers that can scale out as you need and scale back in as you don't need anymore. But these things are running here. So you have containers running here and here and here. Basically, all these three boxes is where you can host a huge collection of containers. I'm just calling them C to represent. And you can scale them and maybe isolate a bunch of these guys to run one of your applications. Let's say the orange-colored containers are running my application called Orange. And the magenta-colored containers, these three, are running my magenta. And you can basically divide the container space that you have in terms of whatever applications you want to run. And have a load balancer container manage traffic from people who are going to visit your, what was the name again? I forget. The name was Vanity Knapsack. And so that was the name. It seems like it succeeded because I remained patient. Because I was not looking at the screen, and that's the key to success. Don't look, because I tend to break it. And so it seemed to have succeeded. And so you saw it build successfully, push the image to private registry, and it's launching. So Vanity Knapsack version 2 was deployed today. And here is the URL. So we got that URL. It is mapped automatically to hello.cloudgd.us. And that's the URL I want to grab and give it to you for you to try. And here it comes. And I will also try in my browser. And you see that I'm getting a container ID, which is this number. It is running in that 17 brother file. That's the container we have that one in running. And so that is just one container. All of us, if we visit that, it's just one container ID that we will see. And that's not really enough to scale. So we want to scale it. And we can scale it to, say, three containers. So we can just go. By the way, did you succeed in opening that one on your side? The link I gave you in Slack chat? The first one or? The last one. The very last one, this vanity Snapsack. So now I'm going to scale it. And scaling the application is very, very simple. Just running that command, which is here. Scale it to three containers, please. So it says, OK, go have some coffee. It is going to scale for you. But first, coffee. Just a way of saying that, please wait. And so I'm going to wait for it to scale. And you will see that the same application gets scaled up. And so scaling is so easy. I mean, it is ridiculously easy right now. If you see what I'm doing, what I'm doing is basically saying that scale my apps to three containers right now, not just one. So this vanity Snapsack that I have, I'm running in just one container. I would now have three containers running the same app. And it doesn't need to be on this box. It can be anywhere. It can be dynamically allocated. Actually, if you go around Robin, it will go like this. So three containers, three machines, spread them out. And then if you have more containers, it will go like this. So see here, see here. Sorry, I should write better. So writing it again, I should write it like this. So see one container. It runs on one of those boxes. We don't know where exactly it runs, but we don't care. As long as we can operate and open the URL that we have called vanity-snapsack.hello.cloudgini.us. This domain we have given and the subdomain we have chosen, the wildcard DNS will kick in. And it will pick up this vanity-snapsack name, vanity-snapsack, whatever that name is, and will map to these three boxes in terms of a wildcard reference. So it can be anywhere, wherever it could run. It doesn't matter as long as you have a corresponding wildcard DNS entry for these IP addresses. And you run only one container. It happens to be on this box. That's fine. You can scale it to two containers. It will go here. Scale it to three. It will go here. Scale it to four. It will go like this. Five, six, seven, eight, nine, 10, 11, 12, 13. And so you will have these many containers running in these different boxes. And if you have a larger scale infrastructure, you can spread the love. Basically, it will automatically spread the love for you, depending on how complex your needs are from an infrastructure and application deployment perspective. It will automatically scale. It is scaling right now for us to three distinctly different containers. And you truly don't know which machine is running, but you don't need to know because there is no need for you to actually understand that level of complexity because this is going to hide from you. And hiding is a good thing because it, by the way, did. So it said, have some coffee. And it says, done in 160 seconds. Vanity knapsack processes, three of them are up, where one, where two, where three. Three containers now are running. So let us hit this URL simultaneously, all of us. Go to paste that link one more time, hit it, please, and just see what the numbers that come back in terms of container ID. They will be different for all of us. So even for me, if I keep refreshing, I'll see my container IDs are rotating between 55, 17, and rather delta. 55, 17, rather delta, like that. So it is going to rotate like this, meaning the traffic is rotating something like, you know, I have only three containers. Right now, not 13, three. So I'm basically getting container IDs, rotating people who are hitting the boxes, hitting the vanity knapsack URL, randomly getting assigned to this, then to this, then to this, and then this, and then this. Actually, I should not point to the boxes because that's incorrect. I should point to the containers. The traffic goes to this, then to this, then to this. That's how the traffic is rotating in a round robin fashion. It doesn't matter where the container sits. It's going there. And you can see this by repeatedly hitting the same URL. You can observe the same behavior on your side by just hitting and refreshing your browser. It will rotate your traffic. And sometimes it will be random because all of us are doing it at the same time. It will randomize, it will leave it. That's what you're looking at from the scaling perspective. We scaled to three. Now, let us scale it to some more, like 13, maybe. There we go. So it's going to scale the same thing across 13 containers. And we'll have coffee. And this time it will be faster because it knows how to scale. So scaling to one, two, three, and scaling to 13 is actually a matter of copying the same container logic or creating, spawning multiple Docker containers. And it will scale it out automatically. And it did, it much faster this time. And in 18 seconds, we have now 13 different containers, all mapping to the same URL, this one, which is what you have already in Slack chat, the same one, just hit it again, and you will see 13 different container IDs serving the same application. One, two, three, so many of these. So you have lots of them. And you can scale more. And you should hit. And by the way, there is no downtime as you see. I am going to scale it to 23 or maybe 25. And let's see what happens. At some point, we will hit the limit where the machines cannot handle. But the machines are decently big. And our application is so tiny, it is laughable. And so it doesn't matter. You can actually scale to probably 100 or maybe more. I have never tested the limit. But right now I'm scaling to 25 different containers and I'm having coffee, actually it's coconut. Yeah, it finished. So it conveniently did that. And we now have 25 different containers rotating, serving our need. And you can see the container IDs pop up just like that. So essentially what I did, and this time successfully, is that we have containers after containers spreading the load. And you can keep growing. If you run out of room like that, you add more boxes. You basically bring box like this into the discovery URL and expand your day's cluster. And then you get more room. You've got more capacity to run containers and then you run your applications and you keep going, keep doing. Now let us see some fancy, fancy things that you may want to see, which is the developer friendliness of this thing. So from a developer's perspective, let us go inspect the source code. So we have the source code opening up. This is the source code for the application. And in there, we have this WebRB. This is the actual thing that you see when the application gets opened. It says powered by home and home is powered by days. You can just have some fun here. Powered by cloud genius. Make modifications, right? And running on container ID like this, or maybe not running, but let's call it flying on container ID. Just making some change, right? Tiny little change in the application and I saved it. So I make the change and save it. The application itself has changed. Now I want to see this new application I just created, modified, existing application that I had. I want to change this days into cloud genius. And say, instead of running, I want it to fly. So I made that modification, but I need to send that modification over to my platform as a service. So I need to basically put this in a git commit and say git push, today's. So I need to make the change, add it, and then commit to a git commit, and then push it today's, that's what I'll do. That's what I'll do, so I will need to do that step. Basically, git add, git commit, let it fly. So I committed, so now my changes are incorporated into the git repository. I can see that. In git log, you will see it. It says, let it fly. It was done right now. So now my changes are included in the git repository. All I need to do from a developer deployment perspective is to run git push, days, master. My master is the new master, which is not this, but the new one that I showed you by hand when I was editing the editor. So that's what I will do. I'll repeat the same git push, days, master, and off it goes. It will take my source code, take the changes, push it, go live, and on 25 different containers, it will distribute the application just like that as soon as this thing finishes, and your application is going to go live with the change that you just made, and see how effortlessly we can go send our applications out to the world for them to consume, to our customers, for them to consume our applications, our services, by tiny little modifications and just pushing it. So make a change, push, make a change, push. That's the only thing that the developer needs to do, and they don't have to worry about all that complexity that we have been dealing with since last three hours. It is so easy for them is to just make a change, push. Make a change, push. I mean, make a change, add, commit, push. Make a change, add, commit, push. That's the big cycle of development. So you make a change, commit to it, commit that change, and push. That's it. That's all it takes for the developer. So it's a developer-friendly thing. To run the platform is a nightmare, nightmare, yeah. But actually, it's not really nightmare. It took us like two and a half hours to finish it, and half of the time I was talking, and the other half I was doing, but yeah, maybe one hour. And the reason it takes longer, because I am describing these things to you, understanding DNS, wildcard DNS, creating a separate name server, different zone, different name server provider, and talk while it does set up, and sometimes we run into problems that it did not deploy correctly the first time, the second time, the first time I got impatient, and all these things come into play. And so, but once you have the platform running, from a developer's perspective, all they need to do is focus on what they want the customer to see. So the customer wants to see Cloud Genius here, and they don't want to run but fly the applications. That's totally okay and doable. And we should be able to see that change happening in just a moment as soon as this thing finishes, sending it, and deploying it, and scaling it out to 25 different containers which are currently running right now. Now, our old application version, this is the old version. So we still see the old version, but at some point it will update and show us the new version. It is still showing us the old version, which is expected because our deployment is still going on. Totally expected. So that's what DASE essentially is doing for us, is doing for our developers to make it easy for them so that they can deploy applications at three steps. Change, commit, and push. Change, commit, push. And the wildcard thing is probably a concept that needs to be understood, this wildcard DNS concept. But apart from that, it's not that complex. It's not that complex. And if you want to do a Cloud Foundry thing, it's similar, very, very similar, except there are a lot more bells and whistles. They go along to make it happen. And so that's the reason why we cannot finish it in a three-hour session. That's why we don't do that thing. But it is very similar to what we just did here in this platform, the DASE platform. So this thing scaled, and it is now running the Vanity Snapsack. Snapsack is running the new version of the application, which means I should just refresh to see Powered by Cloud genius and flying on container blah. And 25 different numbers. So just hit refresh and hit refresh, and you see a unique container ID popping up 25 different variations to it. And that's the thing that we have in terms of scaling our application. We can see that we have this Vanity Snapsack running in 25 containers as seen in a real example, live example in that link. Do you see that change popping up on your side? Yes. Awesome. Awesome. Cool. So a cleanup step now. Cleanup is, what we need to do is as we, as we are done with the exercise, there is no reason to leave these machines running. So we want to destroy. The destruction is as simple as changing the word apply into destroy. That's it. And then run the command again. So we have this command. It is sitting in this notepad here. We want to change the word apply to destroy, and then run the command. That's it. So I'm going to copy this and bring it to my terminal. I will come back to the days folder, which is our platform. That's where it is. It knows how to deal with it. That is important step. You need to be in that folder back in order for you to successfully destroy your own platform. And then paste. Or not this, but paste that. The command with the destroy word inbuilt, word destroy. You want to run that command, long one, copy, and then in the terminal, paste. Am I not copying properly a word? Okay, cut, paste. And now paste it here. Yes. So now I'm going to destroy the entire cluster we have, which is all these three machines will disappear as soon as I run this. It says, do you really want to kill? And I said, yes, go kill. So it killed, and we're done. That's it. So our platform was destroyed successfully. It's still destroying. It will destroy immediately as soon as I refresh. And took us, yeah, completely destroyed the whole thing. Nothing is here. I should also go back to my API keys and destroy the token. This token should also die. And here it goes. Token was deleted. And we can also delete the key pair, which was used for days, which is in the security section, and delete the days key pair as well. It is not critical. Deletion of this key pair is not critical, but you can. And it's just a clean form. So just keep your account clean. And that's what we just did in our platform example. Now at this moment, we should discuss, for example, ask and answer questions if you have any. So destruction happened. Let's see if there are anything missing. If you want to update the Terraform tool, you're done. Okay, good. So let us understand what did we do and discuss this a little bit and answer questions if you have any. So I'll recap what we did. What we wanted to do is have a platform for our app developers, for them to take an app, change whatever they want, commit and push to go live. And can you detail a little bit more around the Docker stuff once you get to it? Yeah, let me just quickly summarize this and then I'll do more Docker. Yes, Docker is the most interesting technology today. And I'll do more tons hands-on. I'd like you to do that because it is fabulous. And Microsoft is also coming out. It's on Docker Windows implementation, which is probably you already have internal access to. I have a private beta. Somebody invited me from Azure, so I'm playing with it. It is beautiful. And so we'll do Docker, ton of it, ton of it, don't worry. So application developers, they develop the app, they change, they commit, they push. All that's the only thing they do. Platform developers like we just did today. Our role today was platform as a developer, platform as a service developer. What we needed was to take some infrastructure. Some machines that we have, some droplets, some instances, whatever you call them. And then on top of that, we deploy our platform. We did some DNS trickery, some patience in terms of waiting for things to happen. And then we get our access to this platform by the name, Daze, which is open source. And then we give that to our developers. And the developers will do, make the app, changes, commits, pushes, and go live. And scale also, the developers can comfortably scale by saying Daze and then scale. The command is specific. So you have to scale web equals to number, some number, 13, 14, 25, whatever number you like. You can scale it comfortably and scale it down, scale it up. No need to worry about underlying nuts and bolts. They do not need to worry. Now let's talk about Docker. Or if there are other questions specifically on Daze, go ahead before I jump to Docker. No questions on Daze is amazing. Okay. That's my... Let me just come out of this Daze folder and then we'll do some Docker steps. So I will minimize the work. I said that's because we have to study Daze. It's too complex. Oh yes. Oh yes. Yes, yes. It is quite complex to understand and getting it to run in a live session is a nightmare. You know, I've done this nightmare many, many times. So I know how to get it to dance correctly. But yes, getting it to run on your own is going to be nightmare. I'm just cautioning you. I already did that. But if you run into a problem while you're doing this, I think if you run it successfully yourself, you will actually enjoy and if you run into difficulty, no doubt about it. And please come on Slack chat and talk to me because we will fix it. I'll do a one-on-one sessions with you anytime you feel like and we will fix any trouble you run into and get it to work. If you're getting it to work, it's probably 90% of understanding it because you really know how to go build things around to make it work for your developers, for them to run things in life. So that's what we did today. Now on Docker. So a couple of things that I would like to talk about that are interesting are actually written down in form of exercises right here, just before this module. So there are these Docker examples, module number 16. I would like to play some of these examples that are actually pretty darn interesting, which is what I intend to do in the right side as I follow along on the left. So on the left side, we have some examples. So let's see them and understand and I'll describe what these things are as we follow along. So on this terminal on the right, I'm just going to run a simple command, which is the very first command. And that command I'm doing is basically running an Ubuntu container and run bash command inside. So we'll do that. So Docker run exactly like it says there on the left side, Docker run Ubuntu and then slash bin slash bash, which is where the location is for the bash command. It is inside the bin folder. So if I run it, it will go and pull the image for Ubuntu OS and then it will do nothing and it will quit. And the reason it happens, it does it like that because it does what it's supposed to do and it finishes doing that so quickly that you don't realize and it comes back. So it did something, whatever you said, and it finished. If you say Docker PS, you will see that there is a dead container. This dead container comes from the fact that you ran it and you told it to do nothing. So it did nothing and came up this prickly mare, this container ran Ubuntu and it ran bin bash and came up nine seconds ago, done, it is done. So it did not do anything. If you want to interact with the container, you have to run the command slightly differently, like Docker run, interact with me please for dash i and give me a teletypewriter so I can type commands on it, dash i t, that is important for you to run. And then you say, run this image please and please give me the bash prompt. In that case, you will see that the container actually creates an instance, gives you the bash prompt and then lets you interact with it using a teletypewriter. So here we go. Now we have a different machine. This is a container, number is 4682. And here we are looking at, get, let's see, release this operating system is Ubuntu Janiel Zeras 16.04. As opposed to the one we have in the virtual machine is not 16.04, but it is different. So let's go side by side, open another terminal. Here, the release version is, is 14.04. So you created a new VM within a VM? No, a container within the VM. A container, sorry. This is a container. So that's the thing we got from the lender saying, all right, please tell us. So we have this container running right here. And to start a new... I'm not sure, you probably could toss it, but I would just leave it just in case. It doesn't hurt, just in case they all of a sudden come back. So the idea behind creating a container is conceptually similar to creating a machine, but the speed by which you can see a new container generating is amazingly fast. You know, we ran this command and you immediately got this different prompt. If you start a VM, it takes at least a minute or two, sometimes more. If you go to another cloud and say that, you know what, give me a machine, please. And it'll give you a machine, no doubt about it, but let's see how much time it might take. So a different cloud, it might take a couple of minutes. So you say, click, give me a new machine, click, and give me a machine in Seattle, and click Seattle, and give me a machine in running Windows. And so give me a machine running 90 GB SSD, and that's good. But it cautions you right there. The Windows operating system requires a package that is 45 GB hard disk, and it takes about 15 minutes to complete the installation process. 15 minutes, that's for Windows. For any other OS here, it's going to be like a minute or two, at least. So say like Debian, that warning goes away, but still you know that it takes a minute or two. You saw in DigitalOcean, it takes at least a minute. 55 seconds is the guarantee that they give. But it is too long, too long for containers. So containers just instantaneously start up, because they are not really starting up. It's just a fenced area, a guarded area, a protected area for applications to run. So it's nothing really different. They use the same underlying kernel, even though the releases are different. 16, 14, the underlying kernel is the same. It is the same Ubuntu 14.04 kernel that you have here. So same underlying kernel, but different operating system. 16, 14. At the same time, you will see that if I open another terminal window and say, what do I have running in my Docker containers? It will tell you that, you know what? This bash thing is running right now, and this thing exited. The other thing, it exited about four minutes ago. Let's run it again. It's running again. It exited about four minutes ago, let's run it again. So I designed layout differently, still not big enough, let's go full screen. So here, I'm gonna widen the screen a little bit, so you can read it better. And you can see that this container is still running, and this one exited four minutes ago. This loving Hamilton is still alive, and that is this one, which is the one called 46 alpha two, which is this one, container ID 46 alpha two. And this is the actual VM, so it's not a container here. It says it's the actual machine. This is a container. Now we can come out of this or just leave it running and open one more. And this time, I'm going to run a different operating system, not Ubuntu, but different. Something like docker run busy box. And it doesn't find busy box locally, so it gets the image down. And then I run sh shell. Sh is another shell, like bash shell, like sh shell. So I'm going to run that shell inside busy box container. So here, I have the shell. It's very similar. I'll say cat, exe, release. Show me the release you have. Am I typing wrong or something? R-E-L-E-A-C, no typing mistake, but there's no file like that. However, the underlying kernel is still the same, Ubuntu. So what we are looking at here is this busy box-based kernel. A busy box-based container is running. And that's this window on the right side that I'm going to place it right here. The window on the back, I think I should just close. And so this is the busy box window. This is the Ubuntu 16.04 window. And here, if I say, show me the container's running, it shows that you have a minute ago created this container called busy box image with an ID number of E88. That is this E88 number. And it is called focused point care. That's the name, randomly generated name. You have another container called loving Hamilton, which is this guy, 46 alpha two. And you can create more containers, just like that. So open another container, and say, Docker run IT. And this time, give me CentOS operating system and run the bash shell inside. It cannot find an operating system, so it goes and brings it. And these images need to be locally available, like Docker images. If they're locally available, they will run immediately. If they're not locally available, they will be downloaded. So it is a local image. So it is downloading right now. And once the download finishes, it becomes locally stored in this location. You can see the Docker image is listed. And when the download finishes, it will run the CentOS image in a new container, interactively operate with it through the bash command. That's what we are waiting for this to download to finish. And when it finishes, you will see a CentOS container. While it does that, I'm opening another container, another terminal, and in there, run another container. It's Docker, run. And this time, I want to run Debian operating system and give me the bash shell in there. So it doesn't find Debian locally, so it pulls it down. And that's what I'm going to wait for it to finish the download. When the download finishes, I will have a Debian container in this window, a CentOS container in this window. And I already have the 16.04 container in this and a busy box in here. There are a bunch of different things you can do. So here we have the image downloaded. We have a new CentOS container available. So you can say cat, etsy, release, aha. Definition between a container and an image running. Okay, good. So here it goes. So the idea behind a container and an image. A container is an instance of an image. What does that mean? Container is an instance of an image. It means, practically speaking, you have this file. Let's see, where's the file? Finder. And in there, you have applications, right? A bunch of applications in here. And you will see that somewhere along the way, you will find Skype for Business. Now, this is the actual file. You can delete it or right-click and check its properties. And it has a version number. It is issued by Microsoft Corporation. And it was modified on September 13th, created on August 29th, and it's all that. That's what you see. Skype for Business. So that is the application itself. Now, if I have run that application by double-clicking on it, click, click, it starts Skype for Business, and my password is needed. So I can provide my password, and it will log in. And once it logs in, I should be connected on Skype for Business, and apparently my password is wrong. So what you get to point, this is not the file called Skype for Business. This is the file for Skype for Business. This is a runtime instance. Similarly, you have this other application called... Where is that called? Word, Word, Word, Word, W. Where is Word? Do I not have Word here? All right. Oh, there it is, Word is out there. So here is Word, Microsoft Word. This is the Word.exe in Windows, right? Word.exe file. So I can double-click on this, and it starts Microsoft Word program, which looks like this. So this is the runtime representation of that file here. This is the exe file. This is the Microsoft Word application running. Same idea applies to containers. This is then a one-two image. Image is a file. Image is a file. When you run that container, it becomes a container. So when you run that image, it becomes a container. When you say Docker run Ubuntu, you're running an image. When you run it, you generate a container. So back to here. We have Docker images. We have an Ubuntu image, Debian image, CentOS image, EZbox image. And these are the four images we have. They all came down from a central location. That location. They're all VMs. No, they're not VMs. No, they're not VMs. They're true OS images. They are like VHD for your reference. The concept of the file, they come from here. They come from here, hub.docker.com. And so in here, you will find that I also have my own images. So you can also have your own images. And you can, like an example here, in Cloud Genius, I have a bunch of images available. The Cloud Genius WordPress image, the Cloud Genius Data image, Nginx Proxy image, StrongSWAN image, BitTorrent sync image, Slack In image, PySpark Notebook, Simple Docker, Redis image. And this Redis image is like an image I created yesterday, seven hours ago. And that is a new image that I now have, and I can make use of it. So when I download this image that I have created for myself, I can instantiate that image to run it for real. And you can do that simply by pulling the image down, such as Docker pull Cloud Genius Redis. So it's going to pull that image that I created seven hours ago down to this VM, this location. It's going to come and bring it down. All it does is pull. So because I pulled it, it pulled. So it pulled that image, and it brings it locally. Now, if I say Docker images, I have the Cloud Genius Redis image that was created six hours ago. Now, you'll notice that the naming here is a little different. I have to have this name Cloud Genius in ahead, followed by a slash. For these images, don't have that name. The initial reference is not there, because these are library images. They are assigned and created by Docker themselves. Whereas this is created by me. And so that's the fundamental difference, is that this is created by a customer or a user, and these are library images. So there is also another image called Docker pull Redis, which is a different image than my Redis. So there is a Cloud Genius Redis, and there is just Redis. Now, this Redis is constructed by the creators of Redis software at Docker Hub. So you can go and search for it. Redis, and you will find the official image, Redis, which is called just Redis. Whereas if you look at my organization, and you will find that I have also a Redis image that is constructed by me. And so only people who know me, or who want to use this image can actually, it's a public image, by the way. So anybody can use it. Or if you use this image, then you can make use of the application that I am running. So what the heck is Redis? It's something that I would like you to know if we do not know. Is Redis, is it cache? It's a open source, in-memory, data store. And why the heck am I talking about it? Because I have actually used it yesterday to enhance the performance of our site. This Cloud Genius site you see, it has a layer of Redis on top. And what Redis essentially does is goes back to the database, to the database, and caches all DB queries. And that is one of the reasons why you may notice that starting seven hours ago, when I finished this project, finally, I have been meaning to do it for quite some time, that the performance of this site has dramatically improved. You will see that it almost instantaneously loads pages right now. If I open a new browser, and I go to the Cloud Genius site, it will so rapidly open pages you will not believe. I mean, at least I find it hard to believe. Almost immediately opens up any page you click on, and that is because it is storing the entire databases, all the queries that I have made in the last seven hours or so, are in the RAM and not on the disk. So you will see it yourself, and I'll let you be the judge in terms of performance as to how the site is performing. But I think the performance of this site has dramatically improved. And I have measured it, and it seems to be really fast. Approximately doubled the speed. Without spending a buck, that's the beauty. Without spending a dime or a buck, just spent nothing, just added this piece of application as a layer using a Docker container, like I am describing here. That's what I added. And we have this as an exercise now. So we will do this in terms of building things to put in. So let me draw a quick architecture for you to close on the discussion I want to have for today for Docker. Is the idea here is what we used to have versus what we now have from performance standpoint. Is that this cloud genius site that I keep talking about that all of us use is the same site you have today, except under the hood, I made some changes. That's what I will describe. This is the before, and this is the after. Before it was at the very foundation, there is a database that is a container. Now, on top, there are some application containers. And you can have any number of them as you like. So it is scalable. They all interact with a common database container. These guys get to a common shared proxy. And this proxy is also a container. And the proxy is what you hit when you open the site. In addition to that, there are some additional containers that run some additional services behind the same proxy. And one more container here for SSL. That also goes to the same proxy. So this container manages SSL certificates. This container manages the chat software that we have. And the application itself is scalable. So it will scale out. Even this is scalable, by the way. But it doesn't need to. It's so tiny, it doesn't need to scale. It can handle load, no problem. So the new design, what I have done, is the proxy remains like it was in a container. Then we have a layer of this Redis cache that basically is caching all the queries that are going to the database container. And then we have another change that we have done to do file. So this Redis cache is basically caching the database. There is a file cache that I have added that caches all the files stored in the application containers. And so that file cache is also all going through the same proxy. This is also scalable. And these applications, in turn, connect to the database and will interface. This part is also scalable. So you can have any number of containers as you like, as you grow and shrink. The file cache will cache all the HTML files that you see here when you visit. When you visit, say, this site, whatever you see here are the files that get rendered. And that's getting served by the file cache. The database queries that you see, like, for example, when you go and log in or you have the boot camp access, it is a logged in method. So you need to go actually pull down a particular entry in the sequence here. So you need to go to this exercise. That is available only to people who are members, so who are actually participating. That is accessible only to you. So that's a database query. So this content is actually stored in a database, all of this. And so that is sitting in here. However, when you are visiting this site right now, in the older design, it was getting accessed through the proxy, through the application containers, straight to the database. And the database was getting hit hard. So it was apparently slow, at least to me. I don't know if you saw that. But now, with Redis Cache, what I'm basically doing is all the least, sorry, frequently or most recently used queries on this DB are stored in the cache. And this cache is about 256 megabytes that I have given currently in the design. That stores all the queries from the database. So anytime the applications want to access the database, they don't go directly to the database. They just go through the cache. So that's the change. So the design would be that you go here and ask if you have Redis, hey, do you have that query already, the query that I need to run? And if you say, yes, I have it, then you please give it to me directly from the memory in memory cache. And I will then serve it to the customer. And if you don't have that, then in that case, yes, please go and execute the query on the database. And then store it back in the cache and then give it to the application who will give it to the, through the proxy, go to the customer. And that's the design change I have made. It makes it a little bit complex for us to actually operate, but it works. Now, you please go and tell me after you had a chance to see whether the performance is actually improved or not. But I'll let you be the judge because you are the ultimate judge. I can measure and I can see the site performance, but that's not the point. The point is, you should feel and perceive that the site is actually faster. And if that's the case, then I succeeded. Otherwise, all this thing that I've been doing with Redis and modifying, making the complex, making the infrastructure a little bit more complex than it was before is pointless, right? So we will have more exercises specifically on Docker because that is the way to go forward. Most companies today that are building new applications, new infrastructure, are using containers. In fact, you should read this. How many containers does Google create every day? And so you should see the answer here. Everything at Google runs in a container. And the answer is 2 billion times a week. And so Google runs 2 billion containers a week. That's a huge number. And this is like old news, by the way. This is like 2014 news. So it's probably 2 billion containers every day or something like that. I don't know how many, but some number like that, some huge number. So that's the kind of rate of number of containers started every week is the number recorded in 2014 time frame. That's the May 2014 time frame. And that's the idea of usage of containers is amazingly growing. It is a rock-solid technology. Microsoft has also incorporated that Microsoft Docker. And you will see that Microsoft has its own container technology on Windows Server. And it's going to be released soon as soon as this thing releases. So Windows Server 2016, it's going to be released soon. So let's see if Windows Server 2016 TP5 is available. Does it look like it released? Hey, do you know if it released or what? I think it released. OK. Sounds like it released today or something. Did it release? Evaluation is available. That means it released. Let's see, Windows Server 2016, is it released? You would know. Don't think so. Oh, it shows that. Evaluation ready, man. Yesterday, end of an hour, start of another news. Yesterday. Just be careful. It might be recalled. Uh-oh. Thank goodness I did not say that. I know I did. You can say whatever you like. I don't want to say that. But yeah. It's just a preview, technical preview 5. TP5 is preview. But you know, at the same page, I see that there is this reference, which is evaluation. And evaluation is a release. It's not TP. OK, beta. It's not beta. TP is technical preview. That's a beta. But when you give an evaluation product, that's a full product, except it will time bomb at some point. At least in my MSDN downloads page, I just see only that, but no evaluation copy. I see. Only TP's. TP, then it's not released. But apparently, there's some news going on. So I don't know. I'll find out. But with this, yes, Docker is coming. And when Docker with Windows will come, you know, it needs, as you know, the underlying kernel needs to be Unixy. And so with Unixy kernel, then you can have Linux and all the Unixy operating systems in multiple containers. You can do that. However, with Windows containers, it can be Windows underneath. And so what that translates to is you can run Windows containers across the board. And that will be fine. These are containers, by the way. No VMs. So no VM. No need of a VM. We don't need them. Don't need them. I'm always yelling at you. So let's say we create a Windows VM on VirtualBox on Mac. And on that VM. So Windows VM. OK. And then on that VM, you want to do what? There can I create containers? You mean Windows containers? Yes. There is a condition. The condition is right at this level. And that level is called VM on VM. File system. That has to be enabled. And I'll tell you where it is. So we have to go here and go to Settings. Go to Advanced. See? They even term it VM on VM. And the idea is, where is that? General, basic. Somewhere there is a button to check. And I think it's available only if I think this is it. Extended features. Enable PAENX. Physical address extension. No execute. That's a bit in Vanderpool technology. It's called BTX technology. That bit has to be checked. And then you can run VM on VM, provided your machine is capable of. So I think your machine is probably capable of. But that's an essential requirement for you to make sure that you are actually enabling that switch. That flag has to be enabled. It is enabled by default if you have that. Extended feature of enabling physical address extensions and no execute bit. Let's see. On Wikipedia, you will have more info on this. BTX. When checked, the physical address extension feature of the host CPU will be exposed to the virtual machine. Exactly. That's what you want to do. So that enables VM on VM. OK. I have to disable that in my BIOS now, because your VMs are complaining now about the no VTX support. You got to enable it. You need VTX support. I must be disabled in the BIOS or something. It worked there for a while. But now I'm getting that error on your new virtual machine. You need to enable it, sir. Please enable that. In my firmware. Yeah. In your BIOS firmware or your UEFI firmware, if you have, you need to go and enable. So I have an instruction here to enable that. And I thought I did, because your first VM ran fine. Huh. OK. Interesting. It shouldn't have run. OK. I didn't get the error. I was running fine. So here, does your CPU not support VTX? In that case, the instruction is certain PC manufacturers like Sony and Dell. They think that customers are idiots, and they disable the hypervisor capabilities. Yeah. Mine's a Lenovo. Go figure. Huh. I'll go enable. All right. Have a good night. Enable it to run. Enable it to run. Night all. Yep. Enjoy. And if you give this exercise a shot, and if you're running into a problem, come back on SlackChat, and we'll talk. We'll do a video conference one on one. All right. OK. Good night. I'll pause the recording, and thank you very much. Thanks, everyone.