Hey guys, we are recording this session and today we are going to discuss monitoring. And when it comes to monitoring, what I mean by that is, you know, any kind of system that you put in place, you know, system meaning multiple computers together operating in some place, whether it is cloud, it can be a data center. So basically you have, you know, one or more systems, computer systems of some sorts. And when these are deployed in some location, you have to then, you know, understand what that location is and capture at the system level metrics. System level metrics can mean, you know, broadly three categories, how is the CPU going, how is the memory acting, how is the disk space. And actually these two go together, if I think of it that way. And then there is network characteristics. And so from that perspective, you have to monitor what is going on with our systems from a pure machine perspective, but there's just one aspect of it. The other aspect to really look for is the applications that we run and how is the application being, you know, is it performing well? And we have to have unique metrics for performance of a given application. And then of course it depends on the application itself as to what needs to be measured. Because we cannot just randomly come up with something that is, you know, generalizable. But there are some metrics that we can think of as generalizing, but mostly it is tied to the application for the given type of application that you are running on the systems. One or more of them in some location of your choice or multiple locations of your choice. And so that boils down to the application itself, mostly speaking. But even on top of all this, there is a critical thing to measure in which is very, very difficult to measure. And that is what do customers perceive? Customer perception, customer perception of performance. That part is really, really hard to measure. Very difficult. The easiest way to measure this is very difficult. And that is actually to ask the customer, hey, what do you think we are doing? How are we performing? Is it good or not good? It's a simple black and white question that you can, you know, in most cases, you cannot ask this question to your customers because they are probably not accessible directly or they don't understand how to measure it or they might give you subjective responses. So these things are really, really difficult to get to a concrete number. If you want to get to a concrete number, that is hard because it is very subjective. It comes from the perspective of the people that are your customers. So it's difficult to measure, very difficult to compromise and things of that nature. So we have to use proxy. A proxy is something that is kind of sort of hints at some metric of some sort that captures customer perception of performance of your applications that run on your systems in your clusters, in your computers, in your data center, in your cloud, whatever that may be. Somebody just joined. Let's see who's there. Excuse me. Sridhar. Hi. So I was talking about performance, Sridhar. And what I'm going to do is give you some idea about what are the tools in the industry that are typically used for monitoring. And so we have a set of exercises written here, monitoring your cloud infrastructure. If there is interest, I'll go through these exercises. But that particular exercise is a open source focused product called Nagios. This is the product that I have that example on, which is a very well established industry leading, I should say. Maybe I don't know. I don't know that leads the industry anymore or not, but it used to be really popular. It is still popular in large enterprises. It is called the industry standard in IT infrastructure monitoring, Nagios. And it is open. It is available on Linux and Windows and other places. You can use it to do a bunch of monitoring for your applications and for your service servers and infrastructure as such. It is used by big companies, as you can see the names here. And more importantly, you can just download it for free, as in deliberate, get the source code and modify it if you like. And so that is available as a part of your distribution of operating systems by itself. Most distributions provide you in Nagios package, so you can just install it effortlessly. Similar to this Nagios thing, there's this thing called Ganglia. Also a very popular scalable distributed monitoring system for HPC systems like high performance clusters and grids. That's another one. And slightly newer one is this. It is also open source. It's available on GitHub and you can get better looking, modern looking dashboards and other capabilities from this. This looks like the commercial version of the same product that I'm talking about, but that is not what I wanted to talk about. So let me go back and look for the open source version, which is right here. And that piece is open. And so that Sensu app is a commercial implementation you see here. You can use them as a service and you can pay them money and they will maintain the infrastructure and monitor for you, but you can run it yourself. That is the open source source code. So you can basically run it on the list of supported platforms. You can grab it on installation steps and find out what is needed and make it run on your infrastructure to help you monitor that thing. So these are the three popular ones, Nagios, Ganglia, and Sensu are the ones that are being open. There are a certain number of commercial products also available here. One of them used to be very popular is this one called New Relic. Why is it not opening? Apparently the New Relic certificate is bad. Is it? Looks like it. That certificate is broken. Let's check another browser and opening up, is it still actually broken or what? And so let's go new relic.com. Yes, the certificate is broken. An amazing thing that is, I don't know what's going on with that company, but I don't care. So remember there is this company called New Relic that seems to exist, but today the certificate is broken, which means I cannot go there. Or maybe I can override and go there. I don't like ugly things. So I will try to see if overriding works, but it will work, but I don't like ugliness. So New Relic is a commercial company, their certificate is broken. I already dislike them. So that is a reason not to use them right there. So don't bother if the certificates are broken, let's go check. What if I actually override and see what happens? Something is seriously wrong with their company. It doesn't seem to load. Does it load for you? Please tell me. If it loads for you, then maybe something is wrong with me. I don't know, but yeah, don't waste too much time on this. Move on. Moving on, we have other companies like Datadog, for example. This is also a commercial company, it is called Datadog. It has a free trial, so you can try it out. But again, this is a commercial product, which means you have to pay money to monitor your infrastructure. Up to five machines, it's available for free. So if you have this thing, you can just run it up to five machines. It's too small a number for a large enterprise, but good for understanding the product and good for trying it out to see if you like it. It gives you ready dashboards and gives you ability to monitor and understand performance of systems that you may have. And so by the way, these guys also have a Kubernetes setup. I might have a login to them, so let's go check out, see if I can log in. And I will log in and see if they give us some ready documentation. So I have nothing running here, and the way to get this to work will be to install it. Help, resources, quick start, that should take us there, the beginning point. And so you can install an integration that requires you to basically connect your services that you have in whichever location you have, each of these services that wherever you run, you can integrate these guys with Datadog. And so I have experimented it in the past with Docker and Slack connectivity, so I can get reports directly inside Slack if something's going on with my infrastructure, and I can get notified like that. That's how you typically use it. But again, this also is being a commercial product, I would rather not use it. So what do I want to use it? I want to use this thing, where is that, called Grafana and Kubernetes cluster monitoring via Prometheus, all using Grafana. And these two products are cloud native compute foundation products. If you look at that foundation, which you, I think, must be aware of what that foundation is. This foundation is, I think, a sister foundation of the Linux foundation. And it is, let's go see what this thing is, if you're not familiar with it. So it is, I think, a sister of, maybe owned by the Linux foundation itself. And that's what makes it beginning, it right away becomes interesting to me because it is Linux and open. And so that is the thing that I like about this foundation. Again, there are projects, some of these projects are graduated projects. So one of the graduated projects is Kubernetes itself. Then there are other incubating projects that are Prometheus you have, and there are a whole list of things. One of them should be Prometheus, which is what I will focus on right now. There are other products also that are probably in other stages of graduation. Probably I don't see Grafana here listed, but it should be there. Grafana should also be a part of the CNCF product set. I don't see it listed for some reason, but not to worry, it is also open source. So how do you actually get these things to run? We have an exercise for that. So we have the exercise written down here in this location. You can go to that location by visiting the Kubernetes section. And here is what we did the other exercise for the last, I think, one or two days. We spent some time in terms of getting the cluster up and running, trying to understand what the cluster is, and we ran it in a ready solution. To be specific, I think I ran it in Google Kubernetes Engine. So that's where I want to now start another cluster, because I want to do an exercise. So you may have seen that starting up and playing through Kubernetes trying to understand it took us some time. And that is not necessarily the case, meaning you don't need that much time to get it up and running. You will see that it should be fairly quick to just get to a point where your cluster is usable. In a matter of maybe 10 to 15 minutes, you should be all done. And so that's the step, the minimum number of things needed for a full-fledged cluster to get up and running functional on your domain is something that I will now be going through. In the past steps that I went through in this understanding the overview and getting a cluster up and running and finding out what nodes are and containers are and labels and parts and the whole list, we went through these things. But I want to focus today on monitoring this cluster, which means I want to first get the cluster up and running, configure it with certain minimum necessary things so that I can make use of it and then use it. And then apply monitoring of the using Prometheus and Grafana to the monitoring system and add these capabilities to the cluster. So let's understand what we have covered up until now. At the foundation, there are some machines. These machines can be any number of them. They operate together in form of a Kubernetes cluster. In the cluster, you need to have some pods, pods run containers, and you can create pods by deploying a deployment. When you deploy something, it creates these pods and you can create a service. When you create a service, you will associate these services with a variety of pods inside your cluster. This service is like a static IP internal to the cluster. It also has a name, a DNS name within the kubeDNS system. So there is an internal DNS name for that by the name of the service itself. Now once you have this setup, which you can create by creating a deployment and a service, this is one thing, this is the second thing you need to do, there is a third thing necessary for a customer outside to come inside the cluster, and that is to provide an ingress. This is the number three you need to create. And then you map an application that you deploy, so the app gets deployed in here, number one, create a service corresponding to it, number two, create a route for it in the ingress, number three, and then the customer can just ask the ingress, it will map to the service and then it will get connected to the actual application. That is how we will be doing it. So we have to have an ingress created. These are, of course, will be deployed later on once we have an application. This is where we create a deployment and a service once we have the end and ingress for every application. For every application, we need to do one, two, and three. And then the application goes live. If you want HTTPS also, we need to have one more ability incorporated here alongside the ingress and that is certification, cert manager. That is going to give us item number four, which is to issue SSL certificates. And that is something that is nice to have and actually a requirement these days. As I mentioned, your company is, I think, working towards fixing the SSL issue. And I'm happy to see that you have actually listened to what I have said. I've said this to the previous group as well as to your group to have Boeing incorporate HTTPS. And I am very happy to know that you listen. And so that is a nice thing. I see HTTPS right there, except I still see some issues. I'll tell you what issues I see. What I see is that this is not completely HTTPS. If it is fully HTTPS, with every single element inside the site supporting HTTPS, it will look green color here. And I'll tell you what I mean by that. You can see the green color right there. It will say secure, followed by green colored HTTPS. That's what I'm expecting. If it is completely, fully secure, like Google is or like Microsoft is, that's what you should see when you go to Boeing.com. You see the green color secure, HTTPS. That's what you should see when you go to Boeing.com, but you don't. So there are certain elements that are still not secure. And I can even go and identify what is insecure. Apparently there are six warnings and two errors, two warnings and six errors. So there are certain things that are not yet done, but you will work on it. I know you at least listen to people like me telling you to get HTTPS, your act together. And you did. Thank you. I mean, you should thank yourself for doing that. It's a good thing. You need to have that. So having understood that piece, the idea is to get SSL functioning using Let's Encrypt, which is an automated authority and for that requires a fourth component. So that fourth component is a one-time operation to create a cert manager deployed alongside your ingress and that will automatically issue SSL certificates as you create a new application and put that in place. So that's the overall picture. So now from the bottom-up approach, we need to create a cluster, create an ingress like that, and create a cert manager and then start deploying applications, one, two, three, like that. And this is like a one-time step. So I should not actually have it. The corresponding ingress route is something that this is the ingress infrastructure. This is the certificate manager infrastructure. That needs to run all the time so that this mapping between users coming from outside and map to the IP address that we see from the outside perspective associated with some kind of a DNS name that I will use. I think cloudgenius.co is what I use for this demonstration purposes. So I will put some wildcard entry like that and map it to a IP address like that, this IP. And so then any application that I can just throw here will automatically get an SSL certificate and get included and get installed, get deployed, service created, mapping happens. All of those things you will see happen as I do this thing live again one more time. Okay. So let's begin from this point onwards. And then once this setup is ready, we can then incorporate an application. And the first application I will actually run is Prometheus, which will allow us to include monitoring capabilities of this cluster and these applications that will eventually run on the cluster. We'll also include Grafana, which will give us visualization capabilities of understanding what the logging is going on and how is it doing and things of that nature. So those are the one or two applications we will run. And then we'll actually run some example applications to actually monitor its performance. Some example, like WordPress or just you bring your app and we just create a YAML file and YAML file and then deploy it and create a service, create an ingress and it just connects and its performance will show up here. The logs will get collected here and we have to create a dashboard to examine and inspect. This is like a viewer tool. This is a collector tool. So it collects logs in the Prometheus system and Grafana will help us view those things that it collects. So that's the overall game plan that we will be running today right now, beginning with setting up a cluster. Cluster setup, simple task, simple task. Just go to the cluster section and then you have done this already. We have to make sure that we configure G Cloud, which I think should be done already, I suspect. So let's go check whether we have our G Cloud config list, see what this shows you. And so we'll go to that location and say, okay, show me the configuration and we see something here. What do we see? List 1A, new scopes behavior, login name, disable usage reporting, project selected, all of that is good, but no cluster, no cluster. So we'll create one. How do you create a cluster? We have to have a virtual private network, which I think we have already, but I will check. How do I check? We'll have to say G Cloud compute networks list. So we'll see if the cloud genius network is there already. And it should respond back, oh, there is no items. Okay. I must have deleted it apparently. So we'll create a cluster or rather a network or a VPC network. I should say in Google's language, it's called a VPC network. So we apparently don't have it. So we'll create one. How do you create? Just go back here and say, create the network. Now this requires a variable. That variable is here and it needs to be filled up with these details. So let's go fill it up. That variable will be filled up and we will fill it up like that. And that will have our variable ready. So we'll echo it, echo dollar my project. And it echoes correctly. Nice. So now what I want to do is now that the project name is clear, we should be able to also export this public facing ID, my IP address and a cider block. So let me export that also, which is also another necessary ingredient. So I have that. Then I will echo my public facing ID to confirm that I have it received correctly. So I echo it. I see that correct number. Then I establish a virtual private network, which is a virtual private VPC network. So I'll create that in the project name and subnet mode is going to be automatic. So here we go. So oops, did not copy properly. Okay. Cloud copy like that and run it. So it will create a network in my account in Google cloud and report that now we have a network called cloud genius. This takes about a minute. So in the meanwhile, we'll see whether we have enabled billing. Yes, we have enabled compute engine API. Yes, I do. And I will be able to list my networks. Once it is ready, I should see this cloud genius network auto regional already created. I need to also have these firewall rules created. So one, two, and three rules that are necessary, which is one of them is ICMP. The other one is any to any connection between the network, between the VPC network. And then the last one is allow me to access TCP 22. Port number 22 to give me TCP SSH access. Those three rules, we need to have them in place. And we are waiting for the cluster VPC creation to finish. Looks like it finished, which means I should see that my cluster is VPC is ready. And there it is. So I see that now I want to enable a ICMP rule, which is to allow me to ping the machines that's one rule, the second rule is to allow any to any machine to machine communication between the virtual private cloud network, the cloud genius network, which is what the next second firewall rule will be. And that is also takes about 30 seconds. And it's done doing that the second firewall rule. You should be able to access and understand these if you don't understand what I'm doing, you should ask a question and I'm assuming that you do. But actually assumption is a bad idea. So please tell me if you do understand this so that I can move on with the speed at which I'm proceeding. Otherwise, I will little bit slow down to make sure that I answer your questions. So please give me positive confirmation that you are with me. And the third rule is to allow me to get to the cluster with SSH. I am looking for some confirmation, it can be verbal, spoken, chat, whatever it takes slack. Sorry, I was a little late, so I lost but I think I can keep up as you move forward with the example. Okay. Okay. What I am doing Gustavo is to focus on monitoring today. So in a short summary nutshell, what I am intending to do is to help you understand how do you monitor a large-scale cloud deployment in a cluster, which means we will begin with creating a cluster, we'll create an ingress and a certificate manager to allow us to get SSL certificates, we'll map it to a domain of our choice for a wildcard DNS, and then create our applications. Our applications will create in three steps, we'll create a deployment, a service, and an ingress route. These three things will help us have an application ready. The first application we will create will be Prometheus, which will collect the logs. Second one will be Grafana, which will help us view the logs, help us view the understand the state of the clusters to what it is doing, how is it performing, things of that nature. And these three things that we have are already understood, how do you create a deployment, how these deployments create pods, you create a service that will allow and create an internal static IP that will associate a service with a variety of pods that you have. And then this third is an ingress route, which will allow this person to connect through the ingress mechanism all the way to the service, to the pod, and where that's where the application runs. That's how this person can access a thing you run here, your app that you run here, to a DNS name that you call out. That's the plan of action we have completed. We are basically creating a network and some firewall rules. And now we are ready to create the cluster itself. That's what we are heading. So carving out a subnet, which is a simple step, just like that. And the missing pieces, it's asking me to select a region. Why did it ask me for that? Did I not specify it already? I think I want to select US West 1. This is my numeric choice. So my network is already in US West 1. So I should select 15 here, all these choices. And I want to stay in 15. This goes check West. And yes, we are in West. So I want to go US West 1, which is 15 is the right answer. So I'll proceed with that. And it should create a subnet called CG in the network called Cloud Genius. And once that is established, we should be able to proceed bringing up a cluster that requires me to have the CIDR, which I already have, have a project ID I already have. I need to now do the last step to create a cluster up, which means these are the things that are necessary. And I will have to make a little edit. The editing needed is primarily around removing the beta flag, which is not necessary anymore and updating this number to 7. That's the latest I think available. Let's go confirm that every day there may be a new version. It is so frequent in terms of updates in Kubernetes that every other month I find a new update. And that is a nice thing because people are working to prepare and create new stuff in the context of using clusters in the cloud. So if I start a new cluster, it should give me a prompt and a list of version numbers. And now we have 10. See that? Yesterday we saw 197. Now we have 110 too. So I'm going to be brave and just jump right there. One, 10, two, GKE one. That's what I'm going to do. See what happens. 10. Oh, sorry. One, 10, two, GKE one. That is my, I'm going to basically be brave, which means I know what I'm doing, which means I don't really know what I'm doing, but I might fail, but we'll deal with it. That's how it goes. If we fail, we deal with it. But here is the new cluster with the latest and greatest coming straight from Kubernetes version 10, one, 10, two, right there. So I'm going to make a change here. It was a beta command, not necessary anymore, updated the version of cluster. And you can actually, if you're doing for real production, you should get a slightly bigger machine than N1 standard one. It's a little too small for production usage. So the bare minimum decent machine for production usage is actually a slightly bigger machine. Number two, N1 standard two. That will give you about seven and a half gigs of RAM and two CPUs. That's a decent size. So I actually prefer that one. But for academic examples, I'll leave it at one. But for right now, I'll make it two, because we are going to apply a bunch of services. We'll have Prometheus and Grafana. And so it needs more horsepower. And so I'm going slightly bigger. And with that in hand, I'm going to copy it, go back to my machine and create a cluster like that. And it should be done in a minute. The cluster becomes up and running. This is going to give us a 110 cluster like that. And in US West, we are getting in the Cloud Genius Network, in the subnetwork CG. And in my SIDR, I will have the ability to connect. Anybody else will not be able to connect because my authorized network is only my location. I have enabled master authorized networks, which means nobody else can connect. That's a security feature. I am enabling auto analytics scaling. Maximum nodes are one and maximum nodes are 11. That's just some number I put in there. It can be any number you like in your business, in your company. And that's the idea behind, I'm using Core, not Core OS. This is container optimized operating system created by Google. It is based on what? Chromium OS. Chromium is an open source OS. It's a Linux distribution, primarily sponsored by Google. And that's what we are waiting for this Andromeda cluster to up and running. Once that cluster becomes up, we should be able to proceed with our next idea, which is once this thing gets ready, we need to make sure that we are creating an ingress and then putting an SSL certificate, not certificate, but a manager tool to get us SSL certificates for any application that we deploy. These two things need to be in place. These are documented already in our website here. You can see where they are. We'll go there first. We'll see that we have to go back a step and then identify the ingress location, that ingress thing actually calls out how to set up an ingress. And that is the step that I will be following once the cluster gets ready. I have to assign an ingress route to this DNS name that I have with a static IP assigned to the cluster and then initialize a Helm account for the ingress tool. The cluster is up and running. We have it now. Which means we should just be able to alias k equals kubectl, so I don't have to type the whole kubectl thing again and again, I say k get nodes and I get one machine. Come on. There we go. And so there's a machine ready up and running. It is ready and it is 58 seconds old and it is running version 1.10.2 of Kubernetes. And this is the machine name right there. The machine is up. We have one machine running in the cluster. That's it. Because we wanted minimum one, a maximum up to 11, so it will automatically scale as needed. But right now it is at one. So let's go now, initialize our ingress system. And ingress system essentially is letting this guy go inside the cluster all the way to where the actual products applications run. It gives you a route. In practice, what it does is it matches the user with a DNS name that he or she is asking for. So now I want to get access to this.cloudgenius.co. So this gets translated to a service call, which maps to a pod, which may have a container inside and that runs in the cluster. And so this runs here. And you have the name that the user asks for and ingress will translate it directly to a service, service will map it to the pod, pod will run in one of those machines. So that's the mapping we want to establish. And on top, we have to establish HTTPS, which means you have to get a static IP assigned to this whole cluster and then associate wildcard entry, cloudgenius.co, it's a different domain, not the usually used domain. This is like a test domain I use for exercises. So that domain mapped in its entirety to the cluster and the cluster has a public IP. I will actually get a public IP now. And so what I'm doing here is identifying the current context of the cluster. And I get the context. Then I save my project ID in the environment variable, which I already have. So that should already be taken care of. Then I create a static IP address. This static IP address is what I want to map. I want to map to this guy, wildcard entry. And so the cluster static IP, the entire cluster gets a static IP, you have to buy it. Static IP needs to be purchased and you have to pay for it only when you're not using it. When you're using it, it is free. But when you're not using this static IP, not connected to the cluster, then you have to pay for it. Or easier, another option for learning purposes is to relinquish your static IP when you're not using, so you don't waste money. So when you don't need the cluster, you just delete the cluster and you also relinquish your static IP. Remember that. IP needs to go away, otherwise they will charge you money. And you don't want to waste money when you're learning. If your company is paying for it, it's still not a good idea to waste money, but probably company can afford it comfortably. So getting an IP address and you're not using it, you have to pay I think about a dollar or so a month, every month. And then if you use it with a cluster, then you pay for the cluster. And then you don't have to explicitly pay for the IP address. That's why when you use it, you don't pay for it. But when you don't use it, you have to pay for it separately. And that's what I am about to get one. And then I can associate this with a wildcard entry. So to get a static IP, you just get that in the region of your choice like this. So I'll get on the static IP assigned. I'll grab that, put it in my Cloudflare DNS and create a wildcard entry in there. So I'm waiting for my Cloudflare to pop up and here it is. And I log in. And once I log in, I should be able to go to the domain of my choice and go to the DNS section and then identify the wildcard entry and it points to the wrong number. So I'll delete that number and wait for the right number and the right number is now available. We just have to get it. We have to identify what that number is, which is basically right in the next step. So address list should give me the number itself. Address list and here is the address. I grab that address and tell Cloudflare that my cluster is sitting right there. So please go. Go to that location. And so it goes. I'm also creating another record, by the way, the whole domain itself and the top level domain for the top level DNS for that domain also goes to the same address. So I have a wildcard and top level A record, both going to the same cluster, which means any new deployment I have will have a name automatically routed to that destination. Now the idea behind DNS is taken care of. And so we have this association created and we can export the static IP that we have now received in form of a variable that I would like to grab in my environment. So I export that and then echo to test and I'm echoing it. And it is correctly validating that number that I have, which is my DNS. I can even dig my any anything and thing and thing dot cloud genius dot go should automatically point to that same IP address. And this can be anything. It will automatically go to that address like here and you can dig another one. I hope you understand what I'm doing. I'm digging a wildcard entry. This can be any string of characters. It will automatically get routed to that location, which is what a wildcard entry does. This wildcard entry now that we have the wildcard entry in place, we need to install our ingress and then install a certificate manager from let's encrypt. And so that's what I will be doing next. I'm preparing our ingress. Ingress is a package available, third party package from the Kubernetes team. It is called NGINX ingress. That is a separate product. It's available here. That's what I want to install. It has releases, the latest release available is 015.0. That's the one I want to use. And I will be using that. So I will go back to creating a Helm chart. Now this Helm thing I keep talking about is actually an installer software. Let's see what Helm does. Helm package manager for Kubernetes. It helps you install complex software with one line. That's what I will be doing is using Helm. I will install these two tools. Cert manager is another one and NGINX ingress is the first one. These two tools will be installed using Helm. I don't have Helm, so I need to install Helm first like that. And here it installs Helm and it apparently is already installed. So now I want to initialize Helm. But before I initialize, I want to create a Kubernetes service account. This is like assigning a user and a password for Helm to run correctly in the cluster. This Helm thing has a server component also. It needs to run in the cluster as well as here on my laptop. So for the server component to run, it needs a user. The user or rather the credential that I need to create is called a service account and cluster role binding. That is what I need to create and it needs to be created like this. I have an example that already I have saved it right in this location and that is what I want to use to create a login password type permission for the Helm and its server component called Tiller. The server component of Helm is called Tiller. I'm creating a user account, a service account and cluster role binding for the Tiller component. I can do that using this step. That step actually is a YAML file that you saw here. That's the YAML file I want to run that creates a service account and a cluster role binding for the Tiller user and the Tiller user. That's what I will be creating now. That will give me a user to use Helm and Tiller with. I called it. I should have actually applied it, kube apply. So kubectl apply. That's what I needed to do, not just curl. So I will now, this local file needs to be deleted apparently. It's actually irrelevant. So I can just ignore that file that saved. This file got saved locally just now at 1.47, which is the time right now. I can remove that, sorry, 1.47 is basically right now. So what I will do is forget the file that got downloaded for no reason. Instead apply the YAML, the cluster role binding and service account YAML. I am going to apply like that. So it will actually create a service account and a cluster role binding for me in the cluster. And it should respond back service account created and a cluster role binding created for Tiller. Tiller is the server side component of Helm. Now that I have these things created, I can now initialize Helm on the cluster. And that is this action. So now my cluster knows how to run Helm, which means I can just say Helm do this and Helm do that and it will install applications on the cluster effortlessly. And so right now, we have to wait for 60 seconds for the Tiller component to get installed on the cluster side. It should be done by now. So I'm exporting my static IP, which I already have, so I don't need to repeat. And what I need to do next is to actually use Helm to install Nginx Ingress. So that requires these steps. What does that do for us? It says, install the stable version of Nginx Ingress and use the version 15, which is like six days old. So I just updated the latest version for Ingress Controller. And this uses the image that is stored in that location that the Docker image created stored in the Nginx Ingress Controller image location by these guys have created it. So you can see that this guy, this ALEBDF, this person, he created an image that's stored in that location. And version number is 015.0. That's what I'm using right now. Quoio, Kubernetes Ingress Controller, Nginx Ingress Controller, version 015.0. So I'm taking this segment, grabbing it and saying, Helm, please install Nginx Ingress. And so it does. And it reported back that it did. Nice. What I want to now do is install the SSL Certificate Manager for us. So this action is done. What I want to now do is make sure that it is correctly connected and we have to watch for the IP address mapping. So let me read this step that the output that we have. And in here it says, Nginx Ingress Controller has been installed correctly. You may wait for a few minutes for the load balancer IP to be available. What it is telling us is that this IP address that I mentioned here, this IP address for this DNS name, it has to be associated with this Ingress. So Ingress knows that any traffic that comes from that IP address, you need to go send it down to the services. That action we can check by watching the status by running this command. So we'll run it and we'll watch if our IP address is properly tied up. Apparently, I did not type it properly. So there's a quote at the very beginning that needs to be removed. So it removes. And now I'll see if the IP address is associated already. And I see that it is correctly associated, correct, external IP associated with the Nginx Ingress Controller. Beautiful. Nicely associated. And so we can break it. And I broke by Control C and I clear. And now I'm ready to do the next step, which is to set up our cert manager. And so we'll grab the cert manager steps written down here for you. And that step is also using Helm. So it requires this action. Let's see what that action actually does. So we'll do the next action, which involves asking Helm to install certificate manager. And we have to have a cluster issuer created. This cluster issuer basically includes your name, your email address, so that let's Encrypt knows who is asking for certificates. If that is not done, it will not receive certificates. So that is what is a cluster issuer YAML. So we need to get that YAML down in our system and then modify any email address to your email address and then apply that particular cluster issuer YAML also. That is a subsequent step. Otherwise, let's Encrypt will not issue a certificate to you. It will issue it to somebody else like me, if you use my email address. We have to issue a cluster issuer for your email address and then upload it to the cluster so that it knows who is asking for certificates. And we'll now run this cert manager, which will basically install certificate manager on the remote machine like that. Certificate manager will get installed now. Cert manager is a separate product, by the way. I will revisit this just a second. I want to tell you that this cert manager thing is a separate product. Cert manager is from a separate team that are also open source. It is from the JetStack team. This team created that product called cert manager, which is what we are using. It is also very popular and very stable and it works exactly how you describe in this picture. Basically the same flow that let's Encrypt expects. So you have a new service. You want to get a DNS name for it and you want to get a SSL certificate. You basically do an authentication with let's Encrypt and tell who you are and how would you need to authenticate yourself to be the real person or entity that owns that domain and the endpoint where it is connected to. And when that ACME challenge gets validated, you will be issued a certificate dynamically on the fly. You've seen it before. You will see it again today. And that is what a cert manager will do for us. It tells us the cert manager is deployed successfully. And in order for it to begin issuing certificates, you will need to create a cluster issuer YAML. This cluster issuer basically tells this cert manager how to issue certificates and who should receive that certificate. And that is what the next step is. So a cluster issuer is basically a simple YAML file that looks like this. And you want to edit that file before we actually apply. So we will download it first. We have it now. It is called cluster issuer YAML.1. And that means that we already have another cluster issuer from the previous step. And we have these two files. Let's see the difference in the two files. And the difference is in one of the files, it says your email.address. And in one file, it says Nilesh, a cloud genius. So I want to keep the right file and delete the other one. So I will probably delete this new file that we just downloaded. And then check out what do we have. And in this file, we already have my email address correctly mentioned. That's how it should be, your email address as opposed to my email address or this random email address. If you use this name, Let's Encrypt will fail. If you use my email address, Let's Encrypt will issue certificate to me and not to you. And so just understand that that's the change you have to make in a cluster issuer YAML, which looks like this, which you download like that. It is on GitHub. And I created that for you as a sample. You can actually modify the sample and I'll actually make it simple a little bit. Maybe I already have made it simple, did I? Apparently not. So this part is how you should change pretty much like this. Like this part should be edited pretty much like I'm doing it for myself, like that. And then you save it. Once you save it, it becomes that new file. You can grab that file and wget it, meaning download it. Now we have another copy of the same file called cluster issuer and it is in two copies and you can now compare the two and there'll be no difference. Huh? There's still a difference. How come? I thought I just edited it. Oh, GitHub is caching, no, somebody is caching. The website shows Nilesh. It still shows Nilesh, but Curl minus O, what do you show? Cat cluster issuer. I think my system is caching it locally for some reason. The website is showing us the correct file, but we'll edit it again one more time. So let's see how many files we have, we have two. And now this file is bad and this file is correct. And so we'll cat it and we see that the name is, oops, I made a mistake, I'll edit it one more time. Cat cluster issuer and that file needs to be having a email address that belongs to me. Like that. And there should not be any spaces after that. So append, enter and make a mistake, put a dot in there in the email address like that. And now it's clean. Okay. Now I save this file. Now this file needs to be applied so that Let's Encrypt knows who is asking for certificates. So we'll say kubectl, apply this file and it applies. So now Let's Encrypt knows that Nilesh is asking for certificates. So it knows and it will do exactly what we expect. Where did the site go? Apparently I accidentally closed it. Yes, I did. Okay. Let's go there again. So go into the site again, go to the Kubernetes section, look for your ingress section in here, ingress. And the very bottom step you will find this thing called ingress, to look for ingress. So there it is. Go inside ingress and then you will find it that we have created a cluster issuer, the cluster issuer. And that is what I'm looking to find. And so it told us that you have to issue a cluster issuer, which we did. And then this is how the cluster issuer looks like. We have applied it. After editing, we applied it and now it tells you exactly. Now you can bring up any services you like within the cluster and automatically expose them then, a typing mistake, expose then, it should be them via HTTPS endpoint. And this will happen because you will pass DNS challenge that you have already created a wildcard DNS, didn't you? Yes, I did. So now debugging the TLS generation, that's not necessary. You don't need to debug, I think it is done correctly, but we will revisit if it needs to be debugged. So that piece is taken care of. The ingress is ready. The cert manager is ready. The service is basically ready to be used. So back here, what do we have done? We have done up until now created a cluster, yes. We have created ingress, yes. We created a DNS mapping to the IP address for this cluster, the static IP. We did that mapping. Then we created an ingress and a cert manager and a cluster issuer for this cert manager to function correctly with our email address. Now that piece is taken care of. We are now ready to deploy any application we feel like. So we'll begin with a test application. Just throw some test on top, we'll deploy WordPress. Running WordPress will involve us in picking up the example on WordPress from somewhere here and running it. How do you run it? We'll get to the monitoring section soon, but I'm going to just run some application to test out if the cluster is functional. And that is run TLS protected services in your cluster. This should be a ready example. So you want to run some service. This is how you do it. You deploy something, then you create a service, and then you create an ingress. Those are the three steps that I mentioned here already. I said number one, number two, number three. Those are the three things that are for an application. This application example is WordPress. We'll create a WordPress deployment, create a WordPress service, WordPress ingress, and we are done. We should be able to just use the WordPress service after we do these three things. They are written down here, the deployment step, the service step, the ingress step. Now these three things are three YAML files. There is a YAML file here, which we need to grab and apply, another apply, and a third apply. The third apply needs some editing. So that's why we are doing it the edit way and then apply. But after that, we are ready. You can just visit the cluster. But I'm going to see these contents of the deployment YAML itself. So I will grab that and see, inspect what do we have. We inspect and we see that it has a deployment for this name called TutumWP is the name of a WordPress deployment. It has match labels and it has a specification that contains a container with an image running in WordPress and its name is this name. That's the deployment. Now we'll also look at the service YAML. This is the service YAML. The service YAML should be strikingly simple. Curl that file and you will see that it has a few lines. It says service and it exposes itself on port number 80 and it selects this role, role TutumWP. That selector matches this label. So this service called TutumWP will automatically select the selector identified by the matching label and show you whatever is running inside this image in that container, in that pod, in created by the deployment. So it automatically gets selected like the selector says and matches up with the role. So the string here between from here all the way to here, that string has to match whatever you have in the match label and then there is an association established between the service and the deployment. Once that establishes, you can now create an ingress. So this was a deployment, here's an ingress, sorry, here's a service and now the third thing will be an ingress. Ingress is slightly more complicated than these two, but you will see it. Ingress is the third step. So I'll grab that ingress step also, copy it and then since it is slightly more complicated, I would like to open it up in an editor. So how do I open it up in editor? Open a new tab and vi, oh, I should bring it down first. So bring it down as in wbit and then I have the WP ingress YAML file here, locally available. I can edit that file and here I want to change some things. So you can now see a side-by-side comparison of what the deployment looks like, what the service looks like and what its corresponding ingress looks like. So you have this is your deployment, at the bottom you have your service and on the right side you have ingress. Now you can compare what's going on. When you deploy these three things, a deployment, a service, I should say a deployment, a service and an ingress, you will see an end-to-end mapping of these things happen. The name chosen here is this name. You can change it if you like and this is the certificate name by the way. The machine's location is identified by the host name. You should not call it machine, but the service name is identified by this host name. The corresponding certificate for SSL is identified by that string. The string gets a secret, meaning a string receives a certificate which is stored as a secret inside Kubernetes. That's where the certificate is saved in a secret, as a TLS secret inside Kubernetes. That's the class for TLS Acme, true. We have to enable this line, annotation line for the certificate manager to kick in and issue certificates for us. So these lines corresponding to the highlighted portion and that one line are corresponding elements that are necessary for the certificate manager to remember to request a certificate from the Let's Encrypt Authority. These lines here correspond to mapping this domain name with the service name here. This selector matches the string here with the match level here. That's how you have an end-to-end traffic flow. From this location, it goes to the service, the service is this service, which has a name which matches right there. It has a port number, which is what is exposing port number, and so you then have a selector that actually picks up the corresponding containers by the match label string. That's how the entire flow will work when we invoke this step. I know that I have created a wildcard entry, so any string here will work out just fine. What one word of caution? The caution is that you know that I have run this exact step, tutumwp, already like four days ago, three to four days ago. You know I've done it for you. So if you now open that tutumwp.cloudgenius.co, it will show you nothing because there is no such service active right now. It will not show you anything. Now what is the caution that I want to highlight to you? The caution is like this. I have a name tutumwp.cloudgenius.co. That's the name, and I remember I used it four or five days ago, and today I want to use the same name and request a certificate again, and I am repeatedly doing this today. It is too frequent to ask for a cert again for the same name I asked for four days ago. They gave me a 90-day certificate, and I'm asking for a certificate again in a matter of four days, five days. That is too frequent. That is the root reason for caution. The abundant caution you should take is you should not ask for certificates for a name frequently, because if you do ask for the same certificate over and over and over again, you will be rate-limited, which means the certificate will be denied, which means HTTP PS will not work, which is not what you want, and we are running in production mode, so the rate limits are very low. If you're testing, you should not use production certificates. You can request testing certificates, and that rate limit is high. There is still a limit, but that limit is high. You can actually make a mistake and repeatedly ask for a certificate for test, and that is okay. Actually, it's not testing. It's called staging. The staging certificate server, which is separate from the production server. You can say ACME production server, production server, let's encrypt rate limit and see what comes up. Here are the rate limits for your production services. Apparently, the main limit is certificates per registered domain is 20 per week. We are not likely to hit that number today by just doing it like twice in a period of five days, not that bad, but I'm just giving you abundant caution, don't do it too frequently because of the rate limit right there, 20 per week. If you are exceeding that rate limit, it may be a bad idea because you will not actually receive a certificate, which is going to defeat the whole point. Don't exceed the rate limit. That's the key thing to remember. Another thing to understand here is that there is a staging limit, which is slightly higher. Let's go see the staging limits. These are production limits, let's say staging limits, and what are the rate limits for staging? The staging rate limits are 30,000 per week. Rate certificate limit is 30,000 per week, failed validations, 60 per hour. That's a decently big number. You can keep on failing every minute. That's okay. It's not a big deal, but these are staging limits and the end point here is different. It has a different name here, Acme Staging API, let's say encrypt.org directory. That's a different location compared to the production location, which was, the production location was, I think, just prod. You can see what is called, the cluster issuer. This file has a reference to the production versus staging, just like you had a reference to your name, your email address, the same idea, vi, cluster issuer, will show you that it actually refers to production, and here is the production URL. Let us see, there is no staging here, there's no word staging here, and it has your email address. Your email address is still needed for staging, but the rate limit is higher for making mistakes in staging. Don't make mistakes in production. That's the one thing to remember. Okay, back. We need to now deploy this deployment, deploy the service, and deploy the ingress. Once we do these three things, this website comes live. Let's go do that. The cautionary word here is that I know that I am doing it too frequent, but it's okay. It is still within the limit, so it should be okay. It should be working out just fine. It will likely be not denied. Let's go see it. First step, I will deploy the deployment, then service, and then ingress. Let's start from here, and back here, first, begin the deployment, deployment. Deployment, deployment, here we go. First one, deploy a ready-made WordPress container, which requires this YAML that you saw. I'm grabbing that YAML deployment step and invoking right, hello, hello, there. kubectl apply-f, and this YAML file, which is the deployment YAML you saw, apply that, and it gets to the cluster and creates a new deployment. Now, you can say k, get deployment, and you can see the deployment, and it's right there, and it is not available yet, but it's going to come soon. Next, I want to create a service like that, and that is this YAML, so kubectl apply, and run it. Kubectl creates a service, and you can see the service is already up and running. k, get service, and this is an internal service. That is the name of the service, and it is active. It's an internal IP address already, and let's go check whether our deployment is ready, and it is available now. This is running a container, meaning a pod. So k, get pods should show us a totem WP pod running, nice. We still have only one machine, k, get node should show you only one. Because it is a big enough machine, it can handle every single thing, so it's not a big deal. So our deployment is deployed, our service is deployed, now we need to create a route for ingress to work so that people on the outside can actually use the services inside. So this guy should be able to go inside through the ingress to the service, to the deployment, and access the pod that I'm running in the cluster. In my cluster, I have only one machine, by the way, but that's okay, it is expandable. So this piece is missing yet, we'll add that, we'll create now. We will now make room and grab the ingress, that ingress is this file, YAML file. You saw that in here, here it looks like, you've seen it before in the editor, this YAML. I want to take that YAML and apply it to my cluster. So I will go and say kapply-f in this YAML file. And so it creates an ingress point. As soon as it creates the ingress, you should see that a new certificate is issued. And before I actually go there, you should see that this thing, totemwp.cloudgenius.co should fail, and it's failing right now. And it is not private. And that's what you saw, but there's nothing actually, there is no certificate yet. There is no ingress route to that location. So we will create an ingress right now. Here it goes. So it goes and creates an ingress right now. Let's go see kaget-ingress. How many ingress we have? We have one with this domain name. And we'll also check kaget-secrets and then grep for TLS. And so we'll see all the TLS certificates issued to us. We don't have a certificate yet. That's okay. We check our kaget pods in the Kubernetes namespace, rather, kube-system namespace. And in the kube-system namespace, we have these pods running. And one of them is the cert-manager pod. So that pod is what is responsible for getting us certificates. So we'll say klogs, get me some logs for that certificate manager pod. And so this, I want to get the logs for. And I'll say go to the kube-system namespace to get me the logs. And I want to read the logs. So it says that a container name must be specified. Okay. Then I will cert-manager container. So show me the logs. And it says, listening on port, attempting to acquire a leader lease, successfully acquired lease, then starting transit controller, cluster issuer controller, finished processing. Now it is error checking the TLS certificate for secret to Tome Cloud genius go not found. No certificate was found. So preparing certificate with issuer compared with this production endpoint, it says, I am going to issue a certificate and the certificate was issued successfully. Certificate should be renewed in 1438 hours. That means about 90 days, if I am not mistaken. 1438 hours is roughly about 90 days from now. So new certificate got issued. The certificate is stored in the two Tome WP Cloud genius.co location as a secret. And it has finished processing. So now certificate is scheduled for renewal in that many hours, which is about 90 days. And then we should be able to see the certificate like this. And it is our certificate. It has been issued to this DNS name and it is saved in a secret inside Kubernetes. What does this mean? It means our site is up and running. Let's go see it. Go to Firefox and open to Tome WP. Come on to Tome WP.cloudgenius.co and we should see WordPress with SSL certificate already all good and nice. Let's go see it. There we go. So we have a fully loaded complete SSL certificate issued to us like that here. More information. It is renewing, expires on August 19th, which is today is what, May 19th, May 21st. And so 90 days from now, 1,438 hours from now, it will expire. We can view the certificate like that. And it was issued today for this domain. That certificate part is handled effortlessly by the cert manager for us. We can see that our service is functional and it is a fully fleshed, full fleshed WordPress functional already. We can go give it a name and get the site up and running. So I can then apply Prometheus and Grafana and other things. We will do that. Let's get this functional first. And this is your WordPress functioning. There is an update available. Let me grab it and say update now. Something went wrong in the update, but we'll handle this later. Leave it alone. Right now it is functional. So we'll just be happy with this. Now with that functional, let us do the next step of actually applying Prometheus and Grafana to see the performance collection of logs and other things of the details. So let's go see that. How do we see that? We have to first of all understand what does it take to, by the way, we opened HTTPS to toomwp.yourdomain and you should see TLS and all that good stuff. We saw that. Okay. Now back to the front page on Kubernetes, but I want to now go to monitoring section, which is right somewhere here, monitoring right there. And if you go inside monitoring, it will walk you through how to deploy Prometheus. Before we deploy Prometheus, we need to understand what this thing does and how do we actually use it in real full production in a real example. So Prometheus is Borgman, that is the product, which is a precursor to Prometheus, which is a Google product basically. And this is evolved into, that Borgman has evolved into this. To get started, you can follow these steps. There's a lot of steps that need to happen. Most of these steps have been automated for you in the Helm chart that I will be using. So we are not going through this step-by-step guide, which is fairly long. We don't try to spend so much time on that. Of course you are free to do the hard way always, but I have simplified it for you and you can deploy Prometheus by first of all, planning for resources. What do you want to do with Prometheus? You want to store, collect logs and store it, right? So store it in some storage. So what I want to do is to identify the storage. And so what I will do actually right now is go to my Google account and find out where will I store this data. So here is my Google login, but that is not the login I'm using in my cluster. I have a different login, so I'll log into that so I can see it visually also. And I am going to sign in and then go to the Google Cloud console to understand what do I have. So here is console.GoogleCloud. Come on. Hello. There we go. And so this is Google Cloud for the cluster that you will see the Android made a cluster. Not this year. That one. Okay. Now here you will have select a project. The project I have is Club Genius Labs 1, 2, 3. And there I have a cluster called Android made a showing up. Come on, show it to me. There we go. So this is the cluster in here. I have only one machine. Where is that one machine? Current total size is one and it has the 10, 1, 10, 2 GKE. And there is some storage that I need to have. The storage is in Compute Engine Disks. So let's go see what disks I have currently. I probably have only one disk, maybe two. What are these disks? What are they doing? There is a disk called Android made a and another disk called Android made a. There are two disks separately. And I don't understand why do I have two disks? Well, this must be created with the machine. But what is this about? And when was it created? I don't know. So that is something that I had to understand, where did this come from, because I don't understand it. So we'll ignore it for now. This one I'll ignore. This is 8 GB, a very small disk. This one is the one that I insisted that I get when I get a system that I had said that when I give me a system, it give me 100 GB disk. That's line number eight at the time of creation of a cluster. For every machine that you give me, one through 11, any number of them, you will give me a disk of 100 GB size. I said that at the time of requesting a cluster. So I understand this disk, but I don't understand the other disk, which we'll get to it later. We'll just mark it as something that we do not know yet. But now I have to plan for disk space in storing my logs inside my cluster. So that's what I am really thinking of right now. I want to plan my resources for my enterprise. I want to understand how much memory will I be using. I want to understand how much of disk storage I need to carve out and keep aside so that I can store my logs in the disk and persist it and maybe rotate it after so many days. So you can basically come up with some kind of a calculation. Here is a thumb rule for storage and a thumb rule for memory. So I've given you some quick thumb rules as to how do you size your machine and how do you allocate disk space for logs for your company. So memory, basically default two GB or three or higher is better. I already have chosen a bigger machine for us, N1 standard two, N1 standard two is what I think I selected. That machine type is already giving us a decent amount of memory, seven and a half GB and two CPUs. So it's good there already. But what about disk? The disk part is what I want to focus on. So the storage, how much storage do you need to allocate for your Prometheus? That's what we are really planning for right now and I'm giving you some thumb rules for Prometheus deployment. The idea is to identify how much retention rate you want to have, what are the number of time series that you want to keep track of. And what I notice is that about 90,000 metrics collected for about two weeks, you need to have a size of about 40 gigabytes on disk. And you want to have a retention set to one month, so you create a 100 GB volume for Prometheus data. These are some thumb rule, quick and dirty ideas of estimation of how much storage should I allocate. And so I'm suggesting that we allocate 100 GB. That's the recommendation for these assumptions, 90 kilo metrics collected for two weeks is estimated to be about 40 gigs on the disk. So you want to set retention for a month, you will get 100 GB disk should be okay. Of course, you need to practice a little bit and see how many metrics do you collect, what is the size of the metrics that you are collecting, how many applications you are running and how much are you retaining and all that detail. And then over time, adjust these parameters so that you can get to a stable state when you can plan for a little bit for future expansion and set a size and define that retention, which is also configurable, by the way, using this parameter storage.local.retention. And you can read more about these details at that location on Prometheus website. How do you carve out storage and how do you allocate local storage and what do you do with it? So you can read a lot more about that. But this is a short thumb idea and a quick idea. What do I do? Take 100 GB. That's what I would suggest. Now we have to prepare Helm with certain default values for Helm to reinstall Prometheus. Now we have Helm chart already in use that will help us deploy Prometheus. Now we have to tweak that Helm chart a little bit, tweak as in change the values that we want. So here what I'm suggesting is that we provision the persistent volume of size 105 GB just to disambiguate from this 100 GB disk, just to make it a little different, 105 GB, just slightly bigger, doesn't cost too much. And so that's what I'm doing for the server disk. And for alert manager, I'm allocating a persistent volume storage of about 95 GB, just again to disambiguate, just both of them are actually 100 GB, roughly speaking. And so these are the custom values I would like to use. And I will like to override the default values, the Helm chart with these values. And so I have this GitHub gist created that will set some override custom values for my Prometheus, for my setup. And I will be using these values as override Prometheus values in my Helm chart to let Prometheus know that I want those values as opposed to whatever it thinks is the default. So I am basically overriding some defaults that Prometheus Helm chart creators decided. And to deploy Prometheus, here is the one-liner. And let's grab that one-liner completely. And here is the one-liner. I will put that in a notepad. You will see here that it contains a reference to the stable Prometheus chart. It has a name called Prometheus. And it uses a dash F file reference to a YAML file right there. And this YAML file is basically the one that you saw already that looks like this. The server size and alert manager size. The raw file looks like this. Same thing. The same thing that you saw before. So that's the YAML override I want to grab and put that in line number 10 here. And then take line and 10 together and apply to my cluster. When I apply to my cluster, you will see that a new Prometheus service and a Prometheus deployment with my custom values pops up in my cluster. So I will go and do that right now here and say, go do it, please, create a Prometheus setup for me. Here it goes. So it sets up Prometheus with my custom values that I have chosen in one shot. And here it is up and running. Maybe not running yet. It is still pending. But give it a minute and it will be up. In the meanwhile, let's go read. What's the idea next? Now that we installed Prometheus using Helm, we have done that. And what I want to do next is... Okay, go back to the page I was on right there. And here I have these things. I'm waiting for them to finish. And now you can access Prometheus like that. So the access is this step. By the way, Prometheus is a data collection service. So it runs behind the scenes, not customer accessible, not publicly accessible by default. It is hidden. You don't typically see Prometheus, although you can as an administrator, you can see it. But most users see it through Grafana. So the visualizer is where the people see. You can still... There is some UI element here. You will see that element right now. And we will like to see that through a port forwarding method, because we are not exposing our Prometheus to the world outside. We are keeping it inside, like our WordPress was publicly exposed. So you saw that I deployed in my cluster. We have a cluster of machines, actually only one machine. In there I have a pod running. The pod runs WordPress, there is a service running, the service is mapped to an ingress. The ingress is connecting to the service which connects to the pod, which runs WordPress and is available to the people outside as tutumwp.cloudgenius.co. That's where people are able to access it right now. But this Prometheus thing that I am going to run, there is no ingress. There is a service, there is a pod, which is created by a deployment. And there will be a deployment for Prometheus, we just started that deployment by the way through Helm. And so that is going to be there, but no ingress, which means you and me cannot actually see because there is no route. So I need to create a port forward. And once I create a port forward, only I can see it. So we'll do that port forwarding thing and then I can see it on my laptop. Only me, only on my laptop, only inside the VM. That is what I will be doing right now. And I will confirm what I'm going to run. I'm exporting a pod name. This is the name of the pod that runs in the default space. So let's go check first what the pods that we have running right now. So okay, get pods. And so here we have a bunch of pods now. There are Prometheus pods, one, two, three, four, five, six, six pods running Prometheus alert manager, state metrics, exporter, another exporter, push gateway, server, a bunch of things running. All Prometheus. There is an ingress controller and there is an ingress controller default backend and a Tutu WordPress service running there already. But these guys are Prometheus and I want to see them locally. And what I want to do is actually focus on the server, which goes like this. What I'm doing is the Prometheus component server. I want to get the pod name for that. Basically, I want to grab this name using an export. That's what I'm grabbing. I have a pod name now defined. I'll echo it. And pod name is the server name. I exported out this name. I extracted using kubectl get pods, dash dash namespace default, which is the default namespace. And then I further list and narrow it with a selector. App equals Prometheus, component equals server. It is that server component, which is what I'm interested in. This server component, I want to get the string here from all the way here to here. That is the name of the pod that I'm interested in. So I have captured that in a variable called pod name. So I can then use this pod name as my port forward reference. I'm basically port forwarding to that pod, the server pod, because I want to see it. So kubectl namespace default, port forward, that pod name to my local machine, port number 9090. I want to do a port forward like that. And this is the pod name. It will be forwarding this traffic from port localhost 9090 to that server. So please let me forward my port. So it is forwarding my port to that destination, which means I need to now open my browser, Firefox, in the local computer, in the virtual machine, and visit 9090 localhost. And I should see the pod. I should see my Prometheus pod right here when I visit localhost 1990. And what do you see? You see Prometheus using the status, and there is a lot of detail here. It is basically the place to dump your logs, primarily. And so the view elements are not interesting here. There are lots of metrics that you will automatically start to collect on your cluster, because that is how it is designed for, to run in Kubernetes. Primarily, that's the main use case. Of course, you can run Prometheus in other places, but the default is to run in a Kubernetes cluster. It is designed for that. So that is what you're looking at is the runtime, command line flags used, configuration, rules, no rules defined yet, targets. And here you can see the API server and the nodes. There are two machines up now, apparently. Let's go check that. Are there two machines? K, U, B, E, C, T, L, get nodes. Are there two machines now? Apparently so. We needed more machines, so it was created one for us six minutes ago, which is awesome. We'll go back to our monitoring, and we have two nodes up. We have a C Advisor, which is Container Advisor, another Google product running to help us collect statistics and logs from our containers inside our Kubernetes cluster. That's C Advisor running. There are two containers. There are some service endpoints. There are endpoints to collect metrics that are up and running now. And we should be able to... You can also get a push gateway configured, so you can get notifications to you on your handheld devices. If you are interested in receiving notifications, there's a push gateway available. You can configure it according to what you need for your setup. So you can get notifications in your local handheld device of iPhone, Android, whatever you have. Depending on wherever you want to receive push notifications at. So that's how Prometheus looks like from a backend perspective. We'll use it a little bit. And we'll also look at the brother of Prometheus, which is Grafana next. We'll leave this running. We'll just break our port forward like that. So connection broken. Port forward is not happening anymore. And now we will look at our Grafana deployment. Grafana deployment is also structurally similar from a deployment perspective, but there are different set of values. So here, what I'm doing is looking at some custom values I would like to use. These values will override the default value in the head chart. These values are called out like here in this example. And here what I'm doing is looking at the values YAML, is this YAML file. I have an image that I want to use. The ingress that I have enabled is false. I'm not exposing my Grafana ingress to the world outside. I don't want people to see Grafana, although I can let people see Grafana if I want to, but that's not a good idea. So in an enterprise deployment, you don't want to expose your metrics to the world outside. Although you can. You can just turn this into a true, just say enable true, and that will enable an ingress for you. And then you can let customers view Grafana.cloudgd.us if you like. So it's very easy. You just enable it and say hostname and a T-RES certificate. That should do it as simple as that. And so we can go that route and actually modify it. By the way, this should be modified. The domain name is not cloudgd.us, but it is cloudgenius.co. That's the domain I'm using. So I should change this and this and this, before I run, if I want to enable ingress. But I'm not necessarily in the mood of enabling ingress to Grafana tool, which is not a customer facing tool. So I'll leave it like this and disable ingress, which will, of course, start the pods, start the deployment, start my services, but not make them visible to the world outside. So these are the values I want to begin using. So I will grab these values and then run a helm install. What does this helm install do for us? Let's go see that. So this helm install will run an installation of Grafana. What it does is install the stable version of Grafana in the name Grafana, and it has a dash F reference to this custom values YAML, this YAML. Now this YAML can be any file or a remote location in a HTTP link, which contains some YAML. And I want to grab that, make it locally available YAML, so I can edit it a little bit before I run it. And so that is how you invoke Grafana with this dot YAML. Now this comes from that location, specifically the raw location. You grab the raw and you bring it here as W get that location. And so you have the Grafana custom values. I would like to modify the Grafana values to this dot YAML and then edit this YAML. And here what I want to actually do is modify the host parameter to call it cloudgenius.co. And again, cloudgenius.co. And one more time, like that. And here I'm using a persistent volume for 7 GB, a very small volume. I'm giving it a container name called Grafana. I have modified my TLS values with the appropriate domain name, which is valid for my current design. The host name is also mapped to the same current design, but the Ingress is currently disabled. With that, I am saving this YAML file, this YAML. And with this in hand, I'm going to run Grafana like that. Again, install stable Grafana with this YAML. This will be the override value for the default values. Here we go. We'll get that Grafana going. It should run and it will report success. It does. It also tells us that you can receive your Grafana password. The username is admin. Your Grafana password is here. That's your Grafana password. So we'll copy that and get our Grafana password. And that is the password for Grafana. So we'll use it. But how do we access it? We can access it by creating another port forward, because we haven't actually enabled an Ingress. So our Grafana is going to be accessible only through a port forward. The port forward is pretty similar to what we had before in case of Prometheus. What we will do is, first of all, get pods to see how many pods we have. We have a Grafana pod running now. And we have a bunch of Prometheus running, our 2.2 WordPress running, our Nginx Ingress controller running, and the default backend running. And so this is the Grafana pod that I want to go to. I can go there by port forwarding. So first, I will grab the pod name. And I think there's a copy-paste mistake here. So let me just check. There was an error executing JSON path, item 0, metadata name, array index out of bounds. Let me just check what the error is. The error is basically something wrong in either copy-paste or a typing mistake. Let's go check that. So checking the error, putting all these things in one line. And the last item also goes in the same line like that. So all in one line now. Let's see if the error persists. If the error persists, I'll just bypass it by manually handling the issue. Error seems to be persisting, which is telling us array index out of bounds. But all I really want to get the pod name, which is this name in my hand in the variable reference. I'll just use the name directly. Okay, hold on. Let me get there. So the name I want to use directly, also I can do that without having to worry about these things is to just get pods and use the name just like that, which is what I intend to do to bypass the error and I'll investigate the error later on, but that's the pod name that I wanted to get. So I've got the name in my copy buffer. I will now create a kubectl port forward like that with the pod name in question. So kubectl port forward and then the pod name, that one and port 3000. That's where Grafana runs and so we will let it run. Now it is forwarding traffic from my local machine to that Grafana pod. So I will open my browser and go to the local location, which is localhost 3000. That's where I should see my Grafana and I do see it. I mean, I will see it, it's loading and there it is. Now I have my admin user and the password that I received in my command line, which I don't see it now, but it was there. And so I will go and grab my password from a previous step and there is the password. It was generated by this command, get a secret from Grafana. And so that is the password, we grab it, copy, go to the browser and paste. And this will log us into Grafana and save. Now we are looking at Grafana. We have installed Grafana, we need to add a data source. And so we'll say the data source that I want to add is Prometheus and Prometheus is already at that destination. So that should not be a problem at all. Let's read. I think I must have notes for this as to how do you configure it. So let me read that. I have modified Grafana values to your DNS enabled TLS. Enable ingress and change DNS, exit while saving. Oh, I think I forgot, I mean, I deliberately, I did not enable ingress. So in the next subsequent apply, we can actually enable ingress. And even now we can enable ingress, let's go to that. We can enable ingress to make it do complete, just like we expect. So I'm going to break this terminal, which is handling our port forwarding right now. I'm breaking it. I will edit by this YAML and enable my ingress. So you can see it, even you can see it from your point of view and from your location. So I'm editing that enabling the ingress right now, which is going to allow me to set it to true. And then I delete the false line and save. Now that I have this YAML with the updated value, I have enabled ingress, change the DNS name, exit while saving. I have done that. And now that I have edited initial Grafana install, after initial Grafana install, you can upgrade your Grafana with Helm. And you want to reuse the values that we have here. And so we'll say, you please reuse the values from this dot YAML. And so we'll upgrade the Grafana and this time it will expose itself on a public name. Public name that we have chosen is in this dot YAML, which is grafana.cloudgenius.co. That's the name I have chosen. So I need to check whether I have an SSL certificate issued to us now. So we'll say k get secrets and then grep for TLS. So I should see there are not yet. Not yet. We are still in the process of getting a request, getting a certificate issued to us. When the certificate is issued, we should be able to access the Grafana cluster or the Grafana setup on a DNS name. Until that time, we will keep using our port forward method, which is currently functional. And this should proceed forward. Let's see if this action finishes. We are back to the port 3000 method by port forwarding. We'll revalidate it. And we have our front with a setting of Prometheus. And we should just save this one. Save and test. And it says fill out the detail. I think I gave it name or we had to give a name. Okay. Here is my name for Prometheus, Prome. That's the name, prom. And I will see if I test successfully. Apparently, data source was added successfully, which is nice. So now data source is added, which means we should go back to the front page here in the home and here we have to now create a dashboard. In the dashboard, what I want to really do, let me review this one more time. So I go to the dashboard home and in the home I have installed Grafana, I have created a first data source. My data source was Prometheus, not Graphite, but Prometheus. That's what I selected and put a name there and it got me connected to the data source. And this is the data source I'm looking at. And here I have some dashboard already created for me and I can readily see my Prometheus stats by importing the dashboard and see what I see in the dashboard right there. There should be a new dashboard popping up in my home and I should see the dashboard right there. Where is my dashboard? Yeah, I don't play with this UI every day, so that's a little bit of challenge for me to find where exactly the dashboard is hiding, but it should be here. There it is, Prometheus dashboard. And look at the stats. So show me the stats for Prometheus. And there it is. It's popping up right now. And you will see the statistics collected by Prometheus going forward in the cluster inside Grafana. And we are going to refresh this every so often. It is still loading a little bit and capturing logs as it generates inside the cluster. And this should give us a view into Kubernetes 2.0. We have multiple dashboards that we can incorporate here. And one of them, actually, I'll show you a resource to incorporate ready-made dashboards that other people have created already and we can just use them. And that is something that I want to actually go play with. But before I jump to that, I want to test whether my TLS certificate is issued already or not. So we'll go break it and go check for TLS. And we should now have not yet. Apparently, something is wrong with the TLS for Grafana. It did not generate a certificate for us yet. Maybe we ping it. But I'm not going to spend time on debugging TLS issues right now. It is pinging correctly. Is it going to the right location? I think so. Yeah, it is going to the same location. That's fine. And it should go to the same location because that's where the cluster is at that location. So it should receive a TLS certificate at some point. Otherwise, I would have to debug and diagnose why it did not. But Grafana itself is usable, and we should be able to see our stats accumulating and showing up in our dashboard for unexpected error. What just happened? Refresh. Oh, the tunnel broke. So the tunnel is missing. So we'll go establish the tunnel again. That was the error. So now it is port forwarding correctly. We should now reload, and the tunnel will get established. Now we are back talking to the same Grafana pod, and we now have our dashboard visible in the Prometheus dashboard is usable. Come on, show me that one. And it should show us some numbers. And a few. Not showing yet. But let's go see if I can add another dashboard. Where is that one? Let me just switch to one more idea, which is, I think, important here. And that is to look at other people's dashboards that we can readily consume. So let's go find out where that thing is. Let's say create or import. And that should be the number I put in 162, if I remember right, and load and import. So 162 is a readymade number that I think gets imported into the cluster to show us Prometheus monitoring, and it should show us some numbers here. And they're not loading. Maybe the cluster is too new, and the deployment for Grafana Prometheus is too new to pick up some data here. Today, show me today's data. No, not showing anything yet. Not showing anything yet. We have to identify why it is not showing, but it should show. Maybe we have to give it some time. But in the meanwhile, the other thing I was talking about is Grafana dashboards. And so here, if you see that people have developed Grafana dashboards and shared it out with other people. So for example, here is an example made in China dashboard number 1013. Now, this expects, I think it expects Elasticsearch. But again, we don't have Elasticsearch. So this may not be relevant to our case. Our case is relevant to WordPress. So let's see if there's a WordPress dashboard already. We have a WordPress running already. So there is a WordPress dashboard loaded up available already. No? How come no? Docs, this is a good place to begin reviewing as to what is needed. How do you customize this? This Grafana tool essentially is a viewing tool to view data generated by a variety of sources. The sources can include, let's go back to the front. This can include a bunch of things here. For example, if you decide to create a new dashboard and where is that button that I'm used to seeing and I don't see it yet. Not super excited with this, alerting notifications manage. I'm not happy with this. So I'm going to not waste your time, but change subjects because this is not going the right direction I wanted it to go. It should capture values already by now. It did not. That means something is wrong somewhere and it takes time to identify and root cause as to what is causing the trouble. So I will do that, but not right now. Right now I want to focus on something else, which is the next subsequent topic. So let me recap my thoughts. I will break this terminal connection that we have and go back to what I was doing and summarize what we just covered up until now, and we will change topics soon. So you will see that there is the disks that I have now created, which actually the place where Grafana and Prometheus are storing data, there is this 113 GB disk. This disk here is the one along with the other disk, which should be this disk. These two disks are the Prometheus disks. And there should be another disk for Grafana, which was like a small disk, but I don't know if it is that disk or not. Excuse me. So there are three disks that we have created. I asked for two of them for Prometheus, one for Grafana, and I suspect these are the three disks because the other two disks are for the two machines that we have running. Our cluster, we have two machines, two VMs running. Those are these two machines and the corresponding disks should be 100 GB and those of these two disks are 100. I can see that. The other three disks that you see, the disks number one, two, and three are the three disks. First one is probably the Grafana disk and the other two are Prometheus disks. This is the data for logs collected within the cluster will be automatically stored. Prometheus does collect data of all types of parameters and metrics within a Kubernetes cluster by itself without you having to tell it to do it. It just automatically does. The difference between what Grafana can do is it is programmable, meaning you can tweak it to the way you want, meaning here is where a list of Grafana dashboards that exist. But again, these are official as well as community-built dashboards, which means you can create your own dashboards. So that is what we look at the data stored in Prometheus and present it to you from a UI perspective. Now the issue that we are running right now, I don't exactly know why it is not showing the way I wanted it to see, but maybe there is an error in which we are not properly connecting our Grafana to our... So we have a Grafana tool, we have Prometheus running here and Grafana also running here somewhere. These two are services and pods in form of deployment already, but we have not created an ingress. We are looking at Grafana, we are not able to see the data, not able to see the data. We saw Prometheus, Prometheus collects logs from the cluster, from the applications, from the pods, from the services, from across entire Kubernetes and stores it. The usable part is right here. Then you program the Grafana tool to see what you want to see, which requires creation of dashboards. And dashboard creation is basically creating a JSON file. And how do you create that JSON is depending on what this documentation will dictate. It will tell you how to create a dashboard somewhere here. Features, tutorials. No, getting started, installation. I saw somewhere that you can create a dash, they should be in the dashboard section. They should be... They keep hiding it, moving it away from me, but there is a place where you can start creating your own dashboards. And if you look at any of these readymade dashboards, for example, let's pick some of them. For example, this one is a decent dashboard. So we'll see what that dashboard actually does. And we can actually copy that dashboard directly in form of a JSON file. So let's see where that JSON is. So you click the download and this download is what you need to write yourself. So I'm going to dump that JSON in a editor to see what it does for us. So we'll show it in Finder and expose it in a editor to see what it shows us. So the editor is opening up and here is the JSON, which defines a variety of inputs and some requirements. And this is the file you need to create. It's a fairly long file because it depends on what you need to see. The person has done it for you. You need to create your own dashboards for your companies, for your viewers to see what they want to be able to see. That's the challenge in creating dashboards. You need to customize it yourself or use a readymade solution that you may be interested in. Like for example, this person has created a dashboard for Apache. So that's how it goes. It is hard work to create a dashboard. It is not readily done for you. Sometimes it is there. Sometimes it is not. And most of the times you have to customize it. And the same goes true with other tools, commercial tools. You still have to basically create a dashboard for other commercial tools also. They will not give it to you. They might pay them money and they'll do it for you. But that's the difference in commercial versus open source tools is you hear you have to work it yourself. That's the challenge. Well, let's check one last time before I stop the Grafana exercise. And that is to make sure that I am trying it one last time to see if Grafana loads up properly and shows up some data. And then I'll hang up on this exercise and do something else. So loading up Grafana. And it is not loading. It has a route to the correct location, but it is not connecting me to the Grafana endpoint inside the cluster, which is expected because something is broken. The TLS is not issued yet. Let's see the back end of this by a port forward. And that should let us in. And I am expecting to see at least some data in the dashboard section for Prometheus, but I don't see it readily. That's the challenge. Because I think the data is not flowing properly. That's why it is showing us empty values. So you see the dashboard. And hello. And don't even show me the dashboard now. Is the tunnel active? Yes, tunnel is active. And so what is it complaining about? Timeout occurred. Error creating stream. Timeout occurred. It's a broken, broken deployment. Bad deployment. Bad deployment. Kill it. Kill it. Now when these things like this happen, what do you do? What you do is you basically say Helm list. What do you have? And you see that there is a bunch of things deployed. And so you want to delete them and create them again. And so that is what I will try. When I have a broken deployment, like my Grafana is not responding, error creating to stream, that's a bad sign. And what I will like to do is go to Helm list, see what I have installed using Helm. I have installed a certificate manager. I have installed an NGINX ingress. Where did this come from? No. I have installed a certificate manager. I have installed NGINX ingress. I have installed Prometheus and Grafana. My gut tells me that Grafana deployment did not go well. Did not go well. So I will say Helm delete. Delete purge Grafana. Get rid of it. Gone. Grafana is dead. Now we'll say Helm list. We don't have Grafana anymore. We say cube or other alias k equals cube CTL and say k get pods. And we should not see Grafana. There we go. Don't see it. Now we will install Grafana fresh, clean, fresh install. And we'll say Helm and do a copy and paste from the cheat sheet. And here is how we install Grafana. So we'll say Helm, please install Grafana using this YAML. So it should, has no deployment resources. Okay. And then the upgrade action is not what we want. We want the install action. So where is the install action? The install action is right here. So Helm install stable name Grafana with a dash F flag and this YAML. So the same thing, install stable Grafana with a name Grafana and a dash F flag with this YAML. This YAML contains the YAML you saw before. Install new Grafana and it did. Now let us see if it gets us our admin password. It should. It did give us a password. Now we will see if it gives us a pod name for Grafana and it did. That's the pod name. And it is running. We'll now check our TLS certificates, kgetsecrets. And then we grep for TLS certificates and we don't have a certificate. Something is wrong in Grafana deployment. I will have to debug this, but let's see if we can proxy it. So proxying it through port number 3000 like that. Our pod name is different this time, it is this name, and we are going to go to port number 3000. So proxy it and don't fail this one, please. Now that the proxy is functional, I'll grab my password from here and open up localhost 3000 one more time. And please show me Grafana admin login. There we have it, admin login. And my password is a new one this time, so I'll override that and login and don't update. And here I have to set up a data source. I'm setting up a name here, so some name and selecting a variety of sources for data. The source that I want to use today is Prometheus. You can have Grafana look at CloudWatch, Elasticsearch, Graphite, Influx TV, Microsoft SQL Server, this and that and other things, but I want to focus on Prometheus. And so with that selection in hand and a name assigned, I should test whether it works. I should also check a couple of things here, for example, are the other things necessary? Probably not. Probably not. You can just go with the defaults and save and test. And so it says data source added. Nice. What does it say? Fill out this field. I have filled it out. I'm going to check it again. Bad gateway. I thought it saved and tested successfully. Oh, okay. Okay. Okay. Okay. It is giving me an error because it's expecting me to type this by hand. That is lame. Okay. I assigned a some name, Prometheus, localhost 1990. And then please don't give me this red flag, save and test and show me that it's still giving me error. Save and test data source updated. But why are you failing me? Save and test failing me. It is failing me. Bad gateway. Now, I'm giving up on this, not debugging it. It is not establishing connection to Prometheus. And that's why it is not showing us data that we wanted to see. And as a consequence, we're not seeing anything. Bad idea. So cancel this idea. Breaking it. We'll revisit this in either in the bootcamp or after the bootcamp sometime when I am able to update the problem and fix it. I'll email you guys. If you're interested in Grafana tool, if you're not interested, of course, you can skip and move on. Okay. Let's, let's skip and move on right now because there's no point wasting time. So I think this exercise doesn't have any further steps. If I remember right, you can access Grafana and that's the end of this particular step apparently. I think so. Yeah. So back one step and see if there are anything interesting in the cluster that we want to take a look at before I destroy the cluster and move on with the other idea. So quickly checking, taking a look at what other exercises I have here that are ready for us to use with the cluster. And there is one thing that I do want to tell you about, which I think I did mention a little bit before was a CICD. Did I discuss this with you? Continuous Integration, Continuous Deployment. I'm not sure in the context of, did we do a Jenkins exercise at all? I don't remember. Do you remember anybody? I think no, I don't think we did anything with Jenkins, right? I don't remember either. Maybe but that's the thing that we can very readily run inside our cluster, which is currently up and running. And so what I want to do now is first of all, get rid of the Prometheus and Grafana that is currently running. So here we have K alias, K equals cube CTL and then K get pods, we want to have these pods that are running. I want to delete the Helm chart for Prometheus and Grafana. So I'm getting rid of both. So Helm delete Prometheus and also delete Grafana. Come on, delete quick, get rid of it. It's a big package. There are six containers. So it will kill and come back and say it is done doing it. And in the other end, I'll also want to delete our Grafana tool. So which is Helm delete purge Grafana and then a clean slate. Now we have Helm list with only two items, which is Connection Manager, Certificate Manager and Nginx Ingress. Now we have our pods running our WordPress only and no other application as such. There is Ingress controllers, of course, but that's the control infrastructure. And this is our WordPress running already in our pod. Now in the CI-CD setup, the whole idea is to actually run something in a continuous integration fashion. What I have is two examples to show you in CI-CD. One of them is raw, as in, let me describe what I mean by raw. One of them is raw, which is not ready for full-fledged demonstration. The other one is actually complete. It's a functional production ready tool for CI-CD. This one is raw. We're going to use Jenkins and it is going to run in our cluster right now. That's the first step I will walk you through. And then we will switch over to another example where I have this complete production CI-CD running and I will walk you through an example case where I will actually show you how a CI-CD flows, meaning I will make a change of some sorts in a Git repository and push it. And then I push it, it goes live and you will see the items as it flows through the pipe and I'll walk you through a production CI-CD pipeline and make a change, a little change, little change, make it go live all the way to the end. So you will see that as a complete example as opposed to the raw Jenkins example, which may have several missing pieces because it is not complete end-to-end. We are beginning to deploy Jenkins CI-CD in the very next step. And then we'll switch over here and look at another CI-CD, not Jenkins, something different, but it is also CI-CD. So this CI-CD setup is Jenkins based, which requires a Helm chart. By the way, this Helm tool that I mentioned, it has, but the word Helm actually has to do with shipping, sailboat or things of that nature. And the tool called, rather, I don't understand the Helm itself, the shipping aspect of it, the navigational or water-based activity that is doing with Helm and Taylor and things, I don't understand it. You might understand it better than I do, but what I do know is that it has something to do with this thing, like this nautical thing, this is the Helm apparently. And there is something to do with Taylor that I don't understand for it is, but what I do understand is that Helm is a product and it's available as a package manager. And these guys have created a bunch of different stable charts. So GitHub has stable Helm charts. And what these things are, are ready to use one-liners that will help you install a variety of packages in your Kubernetes cluster. And so these are the stable charts ready. You can see that the ACS engine, autoscaler, aerospike, aeroartifactory, this, that goes on and on and on. It's a long list. One of them is Jenkins. Where is that? Right here. So if you open that Jenkins folder, you will see the Jenkins Helm chart. And there are these values that are default values. So you can override these values, the long list of YAML file that are available. I want to override some of these values. And that's what I will be doing right now in my Helm chart. By the way, as you saw me delete the deployment for Prometheus and Grafana, the two or three disks that we had disappeared, two disks disappeared. This one still is there. And the other two are machine disks, so they're still there. Now in the idea that I want to run with CI-CD, there is a Jenkins values file that I will like to create and use. And this is the Jenkins value that I will customize over and above the default stable Jenkins values YAML. This is a fairly long set of YAML example values that are considered to be sane default for general purpose use, but that may not be applicable to everybody. So you have to change it and you can change it using override default values that I will be using this example, in which case I'm going to use my domain like that. I'm going to allocate a memory size of 512 MB and I'm going to select certain plugins to go with my Jenkins installation like that. And there are a couple of other things that how do I want Jenkins to run. And so you can see those details that I have included as an override attributes to my Jenkins values YAML. And I will be using this particular Jenkins values YAML only to override the default values that are already provided with the chart. The chart is the Jenkins chart for Helm. And I will like to, first of all, download this custom value that I have created myself, which is this file. And I want to edit some things if I need to, but I don't see anything that deserves editing right now because the domain is already correctly mapped to the test domain that I have. And most of the time that's the change I want to typically do, but I don't want to change it. So I'm not downloading it. I'm not modifying it. I'm just using it. My Jenkins values YAML looks like that, which is already good. So I will now take the Jenkins values file and this is the values file here. And install stable Jenkins. When I do that, I should have a Jenkins set up already. And so let's grab this, bring it locally, not editing it, just bringing it down locally. And I have two copies of this apparently, so I'll remove both of them. And then I download it again. Now I have one copy called Jenkins values dot YAML and I will be using that values file in the example, which is here. So helm namespace Jenkins, name Jenkins and dash F is the values file and then install stable Jenkins. And that should install Jenkins and bring it up. That's it. It should bring up Jenkins in a matter of two minutes with HTTPS support. And it should be visible in that location automatically. That's what we said. We have our connection manager in place. We have an ingress route. We have deployments that will be created using this chart. Currently, these things are pending and it is pending and actually creating. So we'll inspect what do we have, KA get pods and see if the Jenkins pod is up and running yet. Not yet. How about KA get deployment? And it is not showing you anything here because the namespace is different. This is default namespace. You will go to a different namespace and then ask for these questions again. So KA get pods in the Jenkins namespace, so you'll see the Jenkins pod is not running. It is running. What about KA get deployment in the namespace called Jenkins and you should see a deployment and it is not available yet apparently. And KA get nodes should have two machines. And what else we're looking at, KA get service for the namespace Jenkins and there should be a service called Jenkins and another service for Jenkins agent, so two services. And Helm list should show us a Jenkins deployment in addition to the certificate manager deployment and Nginx ingress deployment. And this says deployed, but I don't see it available yet. So we'll go check whether it's now available. And it is now available, which means we should have a certificate available, KA get secrets and then look for our TLS certificates and we now have, we don't have, TLS is not functioning. It functioned for two tome WP, but it did not yet work for Jenkins, which is strange. So let's go examine the logs for KA logs for connection certificate manager in the namespace cube system. And so we have to get the full name. This is not the full name. So sort manager is not the full name for the pod. So we'll get KA get pods in the namespace cube system to get the pod name. The name is this. And this is the container. One of them is running a pod called sort manager. So we have to get the logs for, KA logs for that in the sort manager container and in the namespace cube system. That should give us some logs. And so we will watch it. And oh, it says something issued successfully, but what was issued successfully? Oh, Jenkins was issued successfully. Finally. Okay. Great. Jenkins was issued and earlier it was issued to two tome WP, two tome WP, two tome again, two tome. Jenkins was asked for preparing certificate with issuer, issuing certificate and certificate issued successfully. Great. Then we have renewal set for 1438 hours. So that is nice. So let's go see the certificate show up in this list and it doesn't. Why? Let's see the full list and I don't see it here either. Maybe because our namespace is different. And there it is Jenkins TLS issued and is stored in the other namespace called Jenkins. So that means our Jenkins is functional, which means we should be able to grab its login name. Where is the login name? How do you generate it? You generate the login password by typing, get your admin user password by typing this. And so we will type that to get the password out. This is the password. We'll use it in our Jenkins, like that. And there we should see Jenkins with SSL. There we go, admin login. Okay, you see it. And now here, this is the CI CD tool of choice for open source. So by the way, there are many new open source tools for CI CD now available these days. This is just one of the oldest ones. Here you can see that there are updates expected and there are some issues that we need to be updating these things. So we'll update them, all these three things and wait for it and use it, or you can restart when it finishes. So you can just wait for this to finish and then Jenkins will update and the versions of plugins will update and it will then become ready and at that time you can use this tool to integrate into a CI CD pipeline. This takes two minutes for the upgrade to finish. So once the upgrade is finished up, this tool will be loaded up again and we will wait for it. Until that time, we'll talk about the concept of CI CD a little bit again. So the concept of CI CD and its fully functional complete example is what I want to talk about a little bit. You saw this is a raw, just the infrastructure ready for CI CD to function, but there is no code running here that will actually do the continuous integration pieces. So I will now show you a different example, which is a complete live example. And that example is in a service that I use called Circle CI. Now this Circle CI is a service that I have, which is mapped to a repository that I have where I'm storing a new website I'm building. This is the website. And it has some of the content that you probably see here in Cloud Bootcamp about the Kubernetes CI CD setup that you just saw in a different look and feel, the same concept that you saw in this website is also available, the same CI CD setup available here in a different website. Now here is, you will also see the other thing that we just did a little bit ago, which was our monitoring example, where we discussed Prometheus and memory usage and resource planning, and we ran through Prometheus deployment, we ran through our Grafana deployment, and we ran into some issues with Grafana. Now here, the source code underneath this is sitting in a cluster, in a Git repository somewhere in my computer. So here is a Git repo. And what I need to do is make any changes here and push. And you will see the next logical step that will happen is this Circle CI will automatically receive a post commit hook, post commit hook. As soon as I push a change to GitHub, GitHub will notify Circle CI, which is my CI CD tool of choice currently. Just replace CI CD with Jenkins, it'll operate the same way, except our Jenkins is not currently set up to do it like I'm describing right now. So you don't see a live example with Jenkins right now. But you will see a live example with Circle CI. So just imagine that Circle CI is, or rather Jenkins is Circle CI. So just substitute that for mental perspective. But you will actually be seeing Circle CI, not Jenkins. And what Circle CI will do for us is it will look for a post commit hook in GitHub. As soon as the push is made, GitHub makes a commit and it notifies Circle CI. Circle CI will then start a test cycle and then find out if there are any issues. And if there are no issues, then it will make a deployment cycle. And then once the deployment goes, it will go to some bucket. And then it will be associated with a content delivery network. And this content delivery network needs to be invalidated so that the old content that you have here will get cleaned out and the new one starts flowing out. These are the steps that need to be written down in a file. That is typically known as the Jenkins file, or in our example of Circle CI is known as the Circle CI file. So it will be called circle.yml file. These files, Circle CI or Jenkins file or other types of files like that contain the code for CI CD. The code for CI CD contains steps like these, test step, deploy step, invalidate step. And I will now show you the actual live example of this Circle CI YAML. And let's go see that from a top level perspective as to what the action it is supposed to be doing. And I'm going to identify where it is located and open it up for us to see. That location is somewhere in my computer, I'll identify where it is and pull it up. I think the location is this. And here I have the Atom editor opening up the folder, the folder containing the project which contains the source code for this new website that I'm building right now. It contains all the stuff that we have up until now in the last five years or so created and I'm trying to assimilate and put things in order in a fashion which will have a place to basically store every single thing that we cover in our cloud bootcamp as well as the upcoming bootcamp which is currently running in a beta form. I'm running it in a beta right now, this cloud bootcamp with a couple of people. And once that finishes, we'll start this also simultaneously. So the machine learning bootcamp is what I have in mind for the upcoming season in fall. So I'm basically putting all the effort together in one site which will contain data and back end exercises and every single thing in one place. That's the code for that site that you see here. And it is currently in progress, work in progress right now. So that's what you're looking at as I develop this. And what I will now do is make a little change in the Grafana section. So we go to the monitoring section and here I will say something that this Grafana did not work. Or maybe I'll make a little change somewhere here to make it do something different. So I'll just for now make it a tiny little change in the language here somewhere and I'll show you exactly what I'm going to change. So that's what I will like to now identify in the source code. I'll open atom editor and go to the editor and there, this is not atom, this is atom and I'll go to the source code for the Hugo code for content, for cloud, for Kubernetes, for monitoring and then look for, let's say, instead of extract the admin password for Grafana, I should make a change here, instead of extract, I'll say find out. Just a tiny little change, find out the admin password. I just made a change like that. And this change needs to be propagated all the way to the end, to the output website. It should go and here, should say, find out as opposed to extract. That's what I'm expecting to see as a change that I'm pushing and the change should propagate all the way through my CircleCI build. The CircleCI build is in a config YAML that stores the steps needed. The steps involved are a build step and inside that build step, we have further steps to actually get the source code, to check out the source code itself, meaning this entire folder. We restore cache, we run the node dependencies, we save our cache, we run our build, we then create artifacts to deploy in a bucket, we store these artifacts inside a zip tarball, we then run our tests, then we deploy to AWS S3, and then we update redirects. And then at the end, we invalidate cache. This is how you structure a CI-CD pipeline. The broad steps that I mentioned in our example here is a test step, a deploy step, and invalidate step. I just mentioned three of them, but in practice, you can have any number of them. Like I have here, a checkout step, this is the first logical step. Let's go see how many changes did I make in my Git repository right now in my project, in that Git repository. Let us see how much changes I made. I'm going to open up Git status and see what changed. So I changed the only file here called monitoring.md. And what did I change there? I'll say git diff, and it tells me that I changed the word extract and made it find out. That's the only change I made. You saw me do the change. So I made a change in my source code, and I need to now test it locally. So I'll just test it locally. This is a good practice to test it locally, but I don't need to test because the CI-CD will test for me. I know that. And so I will just git add, and then git commit, and then say make a test change. And then it is currently running a quick test for me before even I run a commit. It's a pre-commit test that we incorporated into the run cycle. Before a commit, it actually tested it for me by itself. It ran some tasks for me to test, and apparently it did make that commit. Now that the commit is done, I can check my Git status again. My working directory is clean, and my branch is ahead of the master by one commit, which means I need to git push. And as soon as I push, you will see CircleCI activate. I'll open CircleCI right now and show you where this thing activates. So I'm going to the app, and you will see that right now it is silent, doing nothing. And I see that this is the site which has the master build number 23 deployed already, and it is fixed, and it is finished four days ago. And so that is what you see right now. And it is quiet and doing nothing. Now watch it on the right-hand side as soon as I push. When I push git push, a new commit will be pushed to GitHub. And I'm going to hit now, one, two, three, or rather three. So it pushes to GitHub. Only a tiny little change. It is pushed. As soon as the push completes, GitHub will notify CircleCI that something needs to happen. So you can see that on the right side, it is running a test cycle already. You can now go inside and deeper and see what it is doing. And we'll expand the right-hand screen to the full screen and see what is going on right now. Spinning up environment. So it says image cache not found on the host. So it is going to download an image called Cloud Genius Dr. Hugo. That's the image I used to test. So it is downloading that image, and then it is checking out the code, the code that I have from GitHub is getting checked out. And you can see that it is actually pulling up that code. The code is checked out, then it restores the cache. Then it installs node dependencies for node.js. And once those dependencies are installed, it will actually run through the cycle of testing. Like I mentioned, the checkout part is happening, install node dependencies. This action is happening. Line 22 is doing, it's doing right now. And then it will save the cache and then run a build for the entire website. Then create artifacts, and then save those artifacts, and then run the test. The other step that you would expect to see happen, because this is the file that drives the CI-CD process in an automated fashion. If this is the first time you're looking at CI-CD, it might sound a little weird to use to why do I do this convoluted way, but essentially, it is something that will help us in getting things done through complete hands-free automation, and even test automation is automated and built into the system. So they'll test for us without me having to test every single thing every time, which is something that I want to avoid. So I let the machines test for us. And Jenkins can do that for us, and so does CircleCI and a bunch of other tools. So now, right now, the build step is happening, and it is creating a build for the website. And it is looking all green-colored, which is nice, which means that it is succeeding in building. And once the build step completes, it will start creating artifacts. By the way, if you are familiar with CI-CD, please let me know, otherwise I'll keep describing these things and you might find it boring. So if you use CI-CD already, let me know. Now the test is kicking on. The testing of the site itself is happening right now. And if there are any broken links, it will automatically fail the test and just report that, hey, it did not work out. Any broken links, anything that is not according to specification, it will break right now. And now it is deploying the website to Amazon S3 and now updating any redirects. And once this redirection finishes, it will go and invalidate our cache in AWS CloudFront. And then once the cache invalidates, this word extract will become find out as soon as I refresh the website. So the invalidation has also happened, which means the build has succeeded and the complete deployment has succeeded already in step number 24. Make a test change that I made, a change in the code a little bit. And that whole cycle finished in four minutes. And now everything should be up to date. And here you should see, instead of extract, you should see find out and refresh. And we'll see the words find out right there. So my question to you is, does this give you a perspective on what does CI-CD do for us for a real live example? And pretty much the same way this Jenkins thing works, I accept I don't use Jenkins every day, so I don't have it in a live demo, but this is exactly how we would flow through in getting Jenkins up and running in this location where it is running right now. And you can give it an admin password and the password from here. And you copy the password and go and paste it and write that location and that should log you into Jenkins and you can operate Jenkins pretty much like CircleCI. And here there are two ways to use it. One of them is the traditional way of creating a Jenkins pipeline by creating a job and creating a pipeline like that. A pipeline is basically just like what you saw here in this example. What is a pipeline example where you have steps, step-by-step, like the checkout step and the restore cache step and the run step and the save cache and another build step and artifact step and store step and a run test step and deploy step, you have to write these steps step-by-step in a pipeline. And then say, okay, and that's how you can establish a pipe for a continuous build. And you can keep pushing items through the pipe. That's the old way of using Jenkins. The new way of using is this new interface called Blue Ocean. It looks different. And here also you can create the same thing except it looks different and it actually helps you automate. So you can get GitHub to connect to Jenkins. So here you can get an access key. If you don't have an access key, you just go to GitHub and get an access key from GitHub and say, my test Jenkins. And then you give it permission to read your repositories. And there are those, repo status, deployment, public repo. I think the default permissions are good. So you generate a token, you grab the token from here and then give it to Jenkins. Say, hey Jenkins, here's my token. So connect to my GitHub, please. So it says I'm connected. Now where is your code sitting, in which location? So my code sits in that company, Cloud Genius Company. And then it says, I am finding your repositories. So here you see that I have 246 repositories. So which one do you want to go with? I want to go with this CG site. Now you select that and say, create a pipeline and say, just expects to find a Jenkins file and it is not there because I don't use Jenkins. So there is no Jenkins files, sorry, there is no Jenkins file found in my repository because I don't have it, because I don't use it. But that is what is needed, a Jenkins file. And once the Jenkins file is there, it will automatically build out your stage and your diagram about how the flow is flowing. But here we don't have it, so we have to create it by hand. So we'll just say, you can cancel it out and say, create a new pipeline or go with this and create a pipeline and by hand. So you'll basically start by clicking this button and you have to name a stage. So maybe the first stage is check out source code and then add another step. And you'll actually allocate item by item as to what do you want to execute when things happen at the time of checkout. Basically it could be a shell script. How do you check it out? You can say that I want to check out certain things, maybe a git clone of some sorts. And save and run and like that. And that's how you can flow through and it will create a Jenkins file for you. If you don't know how to create a Jenkins file, maybe reading that one will be a good idea. You can create a Jenkins file and it will tell you how to write a Jenkins file. Like I made a typing mistake apparently. So there is a pipeline syntax and even going through the syntax is a good idea. But even easier is to just click this link. Create a pipeline in Blue Ocean, which is what we are looking at right now in this example. It's a Blue Ocean reference, so if you cancel out and say, okay. And that's what Blue Ocean is, which is this user interface that you're looking at right now in the blue colored website in Jenkins is a same backend, different front end is the Blue Ocean package, which is slightly more user friendly from a usage perspective. The way to get to use this readily is to go through the tutorials that we have here in this website. That should take you a step closer towards running your CI-CD pipes. By the way, a question for you. How many of you already run CI-CD today? Any of you? Nope. Not me. Okay. Okay. Okay. So I think my suggestion if you're into CI-CD would be to look at the free tools like CircleCI. They're very easy to get to. And that's one of the reasons why I use it, it's easy. And so it is free and easy. Another simpler tool like that called TravisCI, which is also free for open source. So Travis is another tool that you may find interesting, which is fairly easy to get CI-CD to function correctly for a given application that you might have in open source. Nilesh, from your experience, which one would you suggest more for an enterprise level CI-CD? I will suggest this. Let me bring up the name. I'm forgetting its name, but enterprise usage is probably this one. The name is Spinnaker and it was recently announced open source. How we build code at Netflix. That is what I recommend that you use in large scale enterprise in your company. The product is Spinnaker, global continuous delivery with Spinnaker. This is now available on GitHub and it is what Netflix uses internally. And I think it is one of the best CI-CD tools for large scale deployments. Now don't begin learning CI-CD with this tool, it is complex. That's why I don't actually talk about this because I'm not super familiar with this yet myself, but I know it is good. There is a book available for free and the setup is available. It requires quite a bit of effort. There are some concepts to understand, but remember that this is open source and it is backed by Netflix, which makes it awesome. Nothing short of awesome. It is beautiful. This is what I recommend that you go investigate later on. But before you get there, please, please get some simple things running like Travis or Circle or maybe Jenkins. If you're in Azure cloud, is that TFS is a good way to go TFS in a team foundation server. They also have the continuation integration. Yes, TFS has it. And if you're using Windows Azure, you should use TFS. No doubt about that. If you're using Azure, TFS, that's a good solution, good solution. Yes, absolutely good solution right there. But problem is, at least problem to me is it is not open source. So I don't touch it. Yeah. Yeah. But in enterprise, if you're using Azure, so this is the best way we already, they might have a license. Yeah. Yeah. Yeah. You're right. You're right. You're absolutely right. If you're, if you're in the enterprise and you don't want to pay money to Microsoft, you go Netflix route. I mean, the route I said you, Spinnaker, Spinnaker is the solution that I recommend. If you don't want to spend money. But I mean, if you have a hybrid cloud solution and you choose, I mean, one of them is Azure, what about if you are planning to deploy something to the Google cloud or AWS, you run into issues with TFS. Spinnaker is the solution for multi-cloud. This is the multi-cloud solution of an enterprise. This is what I would go behind if I'm, you know, if I, if I am in a big company or if I, if cloud genius becomes big one day, I would go this direction. This requires quite a bit of work and I don't need that much, so I don't use it. But this is the direction to go in a multi-cloud complex hybrid setup for large scale scenarios that you may not run into in a small business. But again, for learning purposes, do not begin with this. Begin small, begin circle, begin Travis, get one or two projects going first and then read this book. And then you set it up and there is a Helm chart, by the way. So installation is very simple. Where do you do that? Helm chart, let's see, Helm, Spinnaker should be there. There it is. So Helm chart stable available. So what does that mean? It means you run this one line and your cluster is running Spinnaker. Let's go run it right now. Let's see how much time we have already crossed seven, but whatever. So here we go. We have a cluster ready and we say Helm list. And so we have, what do we have running? Three things. Okay. So we'll run Spinnaker. Let's see what happens. Give it a shot. This is my first time trying it, so no worries. Let's see what happens. The cluster is up. We just run it. See what the default behavior comes up. We'll see it. It's a fairly long established solid product. It requires lots of things and it will probably start a couple of machines and allocate a bunch of resources and disks and this and that and we'll figure out what it does. And yeah, it's already slow. It'll take time. It's a big product. It should have, in a small Helm deployment, it should have finished by now, but that's not the case because it is big and I know it is big, but you can see what it's doing on the other window. You'll see cloudgoogle.com and tell us what you are doing right now with my account in this location and let us see what Google is doing to us. I mean, what Helm is doing to my Google cloud. So here is the cluster and what? You don't have permission. What do you mean not have permission? I am the person who use the project selection, find project selected, Kubernetes cluster. Three machines now. Okay. Group of three machines, which is expected, we have three nodes, it's not ready yet. So it needed more machines, so it is going to expand and become big and that is what is going on here right now. It needs machines. It is going to create machines and then start running Helm. So whatever it takes, it will bring it up and then make it run. And then it should not be too complex, meaning I can handle it probably if it responds properly, I can probably handle it. But for those of you who have never run ACI, I would suggest Circle, Travis, Jenkins, Simpler, much better. This is useful. Spinnaker is absolutely useful. Don't get me wrong, but not the beginning step. It is not your beginning step. Okay. Three machines ready. So let's see what Helm is doing. Still doing something. Okay, that's a sign you have to have patience and I don't think you have the patience at seven o'clock after listening to me for three hours. So you're welcome to hang up if you like, but I will watch it and I'll see what's going on, what's doing and understand what is going to happen when I run this. So I'm here. You can hang up if you like. I'll take off Nilesh. Yeah. Thank you. Yeah. Thank you Nilesh. Yeah. You're welcome. We'll talk again Tuesday and we'll do more architecture exercises. Tuesday? You mean Wednesday? Wednesday. Sorry. Enjoy. Enjoy.