 Well, I'll do the intro. OK, next up we're going to have, Jean-Francois was going to be talking to us about Kubernetes on the next video, that's very nice. OK, so it's something to be kind of educating, fun, and try to motivate you to try the same experience. There's a demo. I have a bunch of raspberry, which are going to make some light at some point. It's to tell me that I have to start the demo, because basically, this is going to build a network. And I'm going to use this. This is basically the O2 of a Tomcat demo I've been doing at some ApacheCon, explaining how we can do session sharing using the Kubernetes cloud in Tomcat. So I'm Jean-Francois Leclerc. I'm working for Red Hat. You can find me on this email, nearly everywhere, on Twitter, on SlideShare. The slides are already available on SlideShare. So if you don't see the small things and you see it better on your laptop, you can just go there. So here I have my Kubernetes cloud made of raspberries. Basically, I have one box here, which is going to provide a Wi-Fi to the O2s. And I have a master running here and two nodes, which at some point should make some light. Actually, both of them are making some light. So these have created a network on which I have to connect to start the demo, which, of course, going to take a while to start. So that's the first thing when you show how to do a demo. Usually, the first thing you screw is like what? You don't have network or something like that. So this demo is basically to show you that you can easily have Kubernetes running so that you can use it with some space, with very little space. You can have an offline demo of your application that you have prepared for Kubernetes. So at some point, I should get network. Hopefully, it's trying to connect to the first demo and fail miserably. OK, I need two seconds. So I'm connecting on this box, and I'm going to tell master to start the master and to start the two nodes. So I'm starting it, and then I will explain how it goes, because it requires some time to start. So it's going to ping the node, and then it's going to start the stuff. I'll go back to the presentation while it's starting. So what I'm doing here is basically I'll take it a bit the other way. I'm using a Fedora distribution on Raspberry 4. The Raspberry 4 is not yet supported by the Linux kernel, I mean the base kernel. So you have to use the Raspberry Pi specific fork of the Linux kernel. It needs to be cross-compiled, so it's quite easy. On the laptop, you have to install the ARM64 cross-compilation tool and build your kernel. You have to build it for Raspberry 4, and you have also to add some stuff that Fedora is requiring, like to have the same way of working for S-Linux. And you have some parameters also to set for Kubernetes. You can find it on my URL there, but there's not so much stuff there. So to build, you just tell that you want to build this config that's building the configuration files, and then you make make image modules, and then you will have the kernel and the modules and some other file you need. Then you need to prepare SD card. Basically, it's easy. I have Raspberry Pi SD card there, where I have installed the stuff. And I can normally show what is inside, you will see. So it's a bit small, but it's readable, no? So basically, this is my card. This is the boot. It is a DOS or a FAT that is going to be read by the bootstrap of the Raspberry. The bootstrap of the Raspberry is done by the graphic card or the bootcamp card, which is going to read this, load the kernel in memory, and tell the kernel that it needs to run on ARM64 version, and then start it up, which is what has been done. And you have the root partition of the Raspberry. I have used a very big card because I also want to run OpenShift on it, and you can do it with 32 without problems. And you probably could use a smaller one, but the smaller SD card doesn't work. So back to the presentation. So you have seen the starting is running in background. The next problem I have is basically I have to set up the Wi-Fi. To do this, you have to wait. You can either copy the file at the right place in the Raspberry Pi. It's doable. Well, it's easy. I'm not going to explain it because I've done it the other way, which is basically just connecting my Raspberry Pi to my router at home. And I make an end map, find out that it's a Raspberry. I have previously copied to it the Raspberry is starting SSH and have my keys on it. So basically, I just have to SSH to it as root, and then install what is needed. So basically, I'm going to get the configuration for the Raspberry 4. I'm going then to install some tools to do. And then I'm going to configure the Wi-Fi. Fedora 31 has some funny kernel feature, which is a MAC address from Luminization. So there, after we did the file, I'd say never because otherwise I have some problem to find my Raspberry. The description of what is running there, what is running on the infra. If you look, you will find a Raspberry Pi network here. Raspberry 3, I guess. You can guess the password easily from my Facebook friends and information. And in my other demo, I'll let everyone connect to it to play with it, but we won't have time for that. So the explanation of how to set up this box is on my blog. You can have a look to it. I can show more stuff on it after the presentation, like open it and show you what you need inside. Because basically, it's going to run Kubernetes without an internet connection. So I need a real-time clock. I need a DHCP and DNS to have all those things running. So all this is explained in my blog, if you want to try it. Just go there and have fun. The next problem I had is, of course, I need to build ARM64 images. The cool thing is, like, ARM64 images, there's a lot that are available. I have tried it with SantOS 7 and the Alpine kernel. The Alpine Linux is good because it's quite small. Basically, what I did is, like, I used this Raspberry and installed OK on it, and Java, Maven. I'm doing Tomcat stuff, I'm so used. So basically, I have built these things. Small notes, like, I was doing the same on my laptop to make sure that I understand everything. Thank you. And then, basically, you need to take care of multi-platform if you want to use the same image name. Otherwise, the first time you start the stuff on the Raspberry is going to take, like, it's a wrong image. So you must make sure you have the right to use the manifest tool in order that Docker is able to put it in the Docker right information. So basically, you have the information that this image is for ARM, this image is for S390, this image is for ARM64, and so on. So basically, it is this. I won't jump in the data. You use the Docker build. You tell him which art you are, and then the important thing is in this file that you have done on the Tomcat demo with the YAML file. On the master, you have to, so this is basically what is running in background. You have basically, I've run this demo several times, so I have to clean it. I have to play a little with EP table. I have to remove the swap because otherwise QB admin does not want to start. And then, I need a Kubernetes network. I have to choose a way to do that. You have a lot of others, but this was the, this is the first one I tried and it worked, so I stay on this one. I'm open to suggestion. I can do tries. It's very easy. It's my own Kubernetes. I can do what I want. We can try it. I can try other stuff. So basically, then I'm going to do whatever you would do if you use Kubernetes. I will basically copy the configuration to my local configuration so I can run on this guy, but I have done that on my laptop. I can run the command on the Kubernetes things. So basically, to install the network is going to something like a QB CTL apply minus F and the name of the file. I have a local copy of the plugin in my repository, but it's just VGET from the original one. On each node, well, you have to do a kind of same thing. You're just going to join your Kubernetes cluster. Basically, you have a command to do that. You just QB admin cluster token create. It's going to give you the token and if you say print on command, it will just basically tell you which command you have to run on the node to make this node join your Kubernetes cluster. And once everything is done, you can make a QB CL get node to see the nodes that are running. We are going to try it. So here, QB CTL get nodes and you see I have the nodes running. Green is obviously the one which is displaying in green. Blue is the one displaying in blue. And master is this one which is hidden in the app node column. So it had been started while we were explaining the stuff. So I have my Kubernetes running. Let's try to have some fun there. So the next fun I want to do is basically move from a Tomcat cluster to a Kubernetes cluster of Tomcats. So basically I have one problem. I'm jumping quite fast. I hope everyone knows what is web and HTTP. So basically I have one problem. The protocol does not have a HTTP one. Does not have a transaction as a persistent connection. So basically you need a cookie to carry this information. And if you are in a cluster, basically you're going to create a cookie and you're going to store the information of the user on the server and you associate it with one cookie. In this case it's the session ID. So basically what I'm going to need is like basically I need to replicate the session information between the two nodes here because of course I can't be sure on which Tomcat the things are going to arrive. So this is the things. So how the Tomcat cluster is working, we choose multicast. We don't have multicast in Kubernetes for the moment. So basically you have to wait, you have to, this guy have to discover this guy. So you can use the Kubernetes API to do that. This is very easy. It's the internal thing. This is like you make a get. Well you need to be encrypted and all that stuff but this is a decrypted version of it. The date is wrong because basically it was a try without the clock working. And you can see that it's going to tell some information like where it's running, especially what I want to know is the pod IP which is the IP inside the Kubernetes network. So basically that with this I'm going to be able to find from this guy, where is this guy? At which IP it is. So I can exchange the session information. So when I will run my small application on my HTTP, I will basically be able to arrive on the right Tomcat and on one Tomcat, but I will have the right session information on both. So basically I don't care on which one I'm arriving because I've been exchanging the session information. QBPing is a bit tricky because you need some permissions. So in this case it's not a big problem but if you're running a real, on a real cloud, you won't have those permissions. You will not ask your administrator so that they give it to you. So there's another way to discover the other node is just basically we name it QBPing. You can look for it. It had been invented by the infinite span guys. So basically here you just make an NS lookup. So basically, well, this is an open chip example. It's worked the same way. Well, the command is a bit different. So basically you make an NS lookup on your namespace and then you're going to find the Tomcat. This is the way this guy is going to discover this guy and this guy is going to discover this guy. So in my demo, in the next page I'm going to see, I have an HDPD running here. This HDPD is going to be able to find the different load balancer. I need to start the demo so otherwise I will run out of time. I will run out of time, no? Okay, so here basically I'm in my Kubernetes cloud and I'm starting my pods. And you can see basically what did I do? It create a namespace, put it on its namespace, then it's up the Tomcat pods. And create a different service. It create one service which is a DNS service so that the NS lookup will work on both of these. And then I have the two Tomcat which are starting which at some point are going to be up, hopefully. So one is running, the other is not yet ready. Okay, at some point they're going to be ready. So what you do in Kubernetes is like, basically you're going to have one Kubernetes proxy on each of those running is knowing the user node. So basically what we do is you can connect on any of those member of your cloud with the right port to access to the service. So basically to create, to make my HDPD which is running here, distributing the load between the two Tomcat. I don't care, I'm going to tell him like any of those member of my cloud is able to do the routing. This is Kubernetes which does the routing for me. What I'd like to mention is like, you need a Docker registry. The Docker registry is running on this box and it's very easy, it's a sample command. You start the Docker registry, the Docker run on the port. You have to be a bit careful so that Kubernetes does not complain because it's a demo, so it's unsecure. One minute, it's unsecure on purpose. You pull the image and then the things have been running. So now my demo should be ready. So normally I could join my HDPD there and then this is the Tomcat running and when I refresh a bunch of time the counter should be increasing and it should be moving from one node to the other and that's it. So basically I've proven that my Tomcat software is working and then the session is shared between the two nodes which are running there and shared between the two port. It's the same if I would run 10 ports, if I scale up as I have only two nodes, I will have, if I scale to three, I will have a two Tomcat running on this one maybe or two Tomcat running on this one and one on the other. And I guess I'm out of time. Yes. If you have a question, you can come to me after.