 Hello out there to anyone watching in Twitchland. I hope a few people are going to join us today. I'm Kazun Fields and welcome to Fields Tested. A reminder before we get started that this is an official live stream of the CNCF and as such is subject to the CNCF Code of Conduct. Please do not add anything to the chat or questions that would be in violation of that Code of Conduct. Basically, please be excellent to each other and respectful and all of that. So a little introduction to Fields Tested. Our goal here is to give Cloud-native technologies a field test. On our last episode, we explored running a personal blog on Kubernetes, but we didn't finish it. We went through exploring what could we run to run a personal blog on Kubernetes and we decided to go with WordPress, which is a very common tool that is used for creating personal blogs. Then we went to Docker and we started trying to figure out if we could run WordPress in Docker, which we did. Then I ran a local Minicube cluster and spun up WordPress on that and then couldn't actually reach it, which was unfortunate. But anyway, so this week we are going to run our WordPress in a Kubernetes cluster in the Cloud. We're going to look at what it takes to actually make that something that is reachable on the Internet, an actual personal blog that you can go to. So that's what we'll be exploring today. Please, please, please post things in the chat and let me know what you're thinking about as we go through, because it's so much more fun when we all learn together and chat with each other. So I know I have a huge amount of fun with that. So, and please let me know if you can hear me and stuff too. Say hello, just to let me know that this is working because it wasn't last time. I'm learning all of this as I go. Streaming is very new to me. So feedback is very much appreciated. So we went over today's topic. Before I jump into it, I do want to remind everyone to click the follow button on this channel. If you haven't done that yet, log into Twitch and follow. It takes 10 minutes after you follow for you to be able to interact with the chat. So if you haven't done that yet, do it now so that we can chat during the show today. And let's see here. What is on the schedule this week? So here on CloudNative.tv, we try to have a show every day. My show here is on every other Thursday at 1 PM, is what I've been doing so far for my one episode. And looks like tomorrow we have Rockodon who's going to be going over Cube CTL which we're going to be using today, which is a lot of fun. How do you all pronounce that tool? There are many ways and I think they're all awesome. And then next week, we have a full lineup of shows as well. Oh, and on tomorrow we have both Rockodon going over Cube CTL and Pop is going to be going over the story of Thanos. Why do people need it? That'll be interesting. I don't know anything about that. Cool. I think that's about it for my top of show reminders. So let's start digging into stuff. I'm going to share my screen. And this one, make this bit bigger. Okay, hopefully you all can see that and I'm going to change my format here. There we go. That should be a little clearer to see. So if you all can see this and I really hope that you can, somebody please type something in the chat so that I know things are working. So if you can see this, this is the Kubernetes document. Yes, thank you. I see and I see it. That makes me feel much better. So if you can see this, we're in the Kubernetes documentation. We've got an example up here that they just have here which is very convenient of deploying WordPress and MySQL, something that we explored last time using persistent volumes in Kubernetes. So last time we just deployed this onto a mini cube cluster on my local machine. So this time we're going to do that in the cloud. If we can, cool. So I have Google Cloud Platform up here. I work at Google Cloud. So this is the tool that I have through work. I'm going to try to point out anything along the way that's cloud specific. All of the steps to do this should be pretty consistent. You should be able to find the right tools to do it, you know, like MySQL. That's how I pronounce it. MySQL, is that what you prefer? So like I said, I'll try to point out anything that's cloud specific. You should be able to do this on just about any cloud provider locally, like we did it last time on local clusters. I have a set of Intel NUX that I deploy clusters on locally sometimes, and I also have, well, I'm about to order some Raspberry Pis, which I'm going to explore running some Kubernetes clusters on. Have you all ever run Kubernetes clusters on Raspberry Pis? I know a few people who have, but I have not done it yet, but I'm going to order some and do it. But today we're going to do it in the cloud because that's one area that I'm pretty used to interacting with and stuff. So I'm making this giant, so it's super easy to see, maybe two giant. So the first thing that we're going to need is a Kubernetes cluster. Since I'm in Google Cloud and I work with Google Kubernetes engine quite a bit, I'm going to use a Google Kubernetes engine cluster. Do you all care about seeing me deploy a GKE cluster? I'm guessing probably not. I already have a cluster up that I can just use. I run QCTL get node or nodes. Good point. I need to go ahead and authorize my cloud shell. Cloud shell is really easy for me to work in, so that's why I'm doing that today. There's a huge variety of different tools, though, that you could use to interact with Kubernetes clusters. Oh, nice. I'll link to someone with an impressive k3s set up on Raspberry Pis. I'll have to check that out later. So you can see that I've got a Kubernetes cluster up here that I'm going to use today. So if I run QCTL commands, I get responses. I have a few pods up and running here already, just one, I guess, and we'll go over what that's running a little bit later. But first, I want to see if I can go ahead and deploy this WordPress thing that we deployed last time locally, just onto this cloud-based Kubernetes cluster and interact with it that way. So to do that, I'm going to follow the same steps that we followed last time. This will be downloading the MySQL deployment configuration file. We went over last time that WordPress requires a MySQL. Is that what you prefer? I'll do that. We're going to download the MySQL deployment configuration file and then download the WordPress configuration file. We went over last time that WordPress needs a database of some sort to do its work. So we're going to be deploying the database alongside WordPress into Kubernetes because that's convenient for us through this example and all we need to do is deploy a personal blog site. So we're going to try that. And add them to the customization.yml. Trying to make sure that I didn't need to download anything else before I did this because I'm working in a new environment. Last time, if you remember, I was working in cloud code and on my local machine. So I already had a few things going on. I'll come back to that. I'm just going to go ahead and run this curl command in my cloud shell, which I'm working out of today so that I'm pulling down the MySQL deployment file that we're going to use to run our database in Kubernetes. And then I'm going to pull down this WordPress deployment which we'll use to run our actual WordPress site which we'll use to create our personal blog site. And add them to the customization.yml file. I guess I should probably go ahead and run this one. Doesn't really matter which order, I guess. So the first cat file we're running, or cat command we're running here, we're going to create a customization.yml file which we'll then use to deploy our WordPress and database. And we need a secret for our MySQL password. So that's what that's creating there. And we need to add these resources to it, the YMML files that we just got through curl. And one thing that we went over last time that I thought was really cool before I run this stuff is we were going over the persistent volume claims and how persistent volumes work kind of in Kubernetes. And myself and at least one other person in the chat kind of thought that we might need to create a persistent volume manifest for Kubernetes because in Kubernetes to have persistent storage, you create a persistent volume claim that says this workload needs a persistent volume and then it exerts a claim on a persistent volume. But this doesn't actually have a persistent volume manifest. You can see here we're defining our persistent volume claim, but the way this is configured it actually kind of auto generates the persistent volume that we will be claiming, which is pretty cool. So I thought I'd point that out because I thought it was really cool last time. And so now it's just saying to run kubectl apply-k. And if you remember last time or you're familiar with Kubernetes at all, you'll be familiar with kubectl which is the command line tool that we use to do things with Kubernetes clusters. K, cool. So I ran kubectl apply-k and it created a secret and it created a service, another service, one for the WordPress one for the MySQL. And then it created the persistent volume claims as well. And we have these warnings here. This is because I'm running in Google Cloud. I'm running a GKE autopilot cluster today. So that's why you see these warnings which are saying that it's going to, well, resource requests for the deployment were not specified, which is interesting. Good to know from the tutorial. So GKE autopilot clusters in Google Cloud, they kind of automatically choose the underlying hardware, underlying compute that your workloads are going to run on. So whenever I deploy something into my Kubernetes cluster, I get these warnings that say autopilot is figuring out what compute you actually need to do that. And it might add compute to do it. In this case, it says that resource requests were not specified. So it's using some defaults which we could go and check out there. I don't care that much. So I'm not going to mess with that. But I do want to check to see if my deployments are up and running. So keep CTL get deploy. Let me know if you all have any questions as I go along with this. I might be going a little too fast or something. So my WordPress isn't up yet. My WordPress MySQL is not up yet. Might take a couple of few seconds to a minute or two. It's already been up for a minute. So probably shouldn't be too much longer. If we wanted to sit here and wait and watch for them to come up, we could run dash w and there you can see them coming up, which is good. So once that's up, if we come back over here, it says that we should check out our secrets. It says that we should check out our persistent volume claim. We might as well. We tried that out last time with our mini cube cluster and we'll do it this time too. So you can see now that my WordPress MySQL and my WordPress deployments are both up fully ready. So I'm gonna control C out of that. Cube CTL get secrets and Cube CTL get PVC is what I recommend right now. Cube CTL get secrets. Cool. So we can see here that we have our MySQL one that we created. So that's looking good. It was created two minutes ago. And then Cube CTL get, let's do PV first. Like I mentioned, it auto creates these persistent volumes. So PV is persistent volume in Kubernetes. So this tells us some information about the storage that we're actually using for our WordPress and for MySQL. Last time we talked a little bit about how there's a folder within WordPress that you need to maintain, state in. The first time I tried to run a WordPress database or WordPress website in containers, I did not do the persistent volume for the WordPress side only for the database. And it lost all of my images when I took my WordPress down to test it out. So it's very important to have that persistent volume for the WordPress side for the folders in that as well as for the MySQL which contains some other pieces that WordPress uses not a WordPress expert. But I know that some of the things were still there when I tested it. One recommendation I can give is if you're not quite sure what something is doing and you have the space and you can test out deleting it and seeing what happens, it's a great way to understand what kinds of persistent volume needs you have. Of course, you might lose things. So don't do it with something that's precious. Anyway, so we've got all sorts of information about those here. And it suggested that we look at our volume claims which would be PVC. And you can see that we've got our persistent volume claims here. We've got our persistent volumes as well as our persistent volume claims. And I know that these can be kind of hard to read because the top row of this table gets kind of a split across the two lines. That's a good wording. So it can be kind of hard to associate things. I'm not gonna go into much detail there but if you find it confusing, let me know and I'll go over it. So we looked at our secrets and we looked at our persistent volume claim and we have our WordPress and our MySQL up and running. Good start. Now, our next thing is to check out our service. And we remember last time this is a load balancer type service that we created so in Google Cloud with GKE that should automatically create me a load balancer resource in the cloud that I can use an external IP to get to our WordPress. When I was running it locally on Minicube we just used our node port here in order to reach the WordPress application that was running. So note Minicube can only expose services through node port. It's exactly the situation we were in last time. The external IP would always be pending in that case but now we're in the cloud so this is gonna be a little bit different. So kubectl get service and it recommends specifying the service name WordPress, right, yep. So kubectl get service WordPress pool. So we can see this here. I'm gonna copy my external IP and put it in a separate tab in Chrome and there we go. So now we have WordPress running in the cloud. That's awesome. I'm gonna go ahead and set this up. Fields tested rocks and fields test in and give it a password. This is fine. I'm just gonna use this for this demo. What mail to put in? Do I have to put one in and discourage search engines from indexing the site? I guess I'll do that. I must provide one. Okay. Let me decide what I'm gonna do here. Let's do this. There we go. So I'm logging into my WordPress right now that I created. Very nice. If I log in, now I have to go to my login because I've created an account. I went to WordPress for the first time since we deployed it onto our Kubernetes cluster and I created an account. My name did fields tested. Okay. And so now we're into WordPress. So I already got a bunch of updates for me. It's good to know. It's got some pre-installed plugins but let's look at what the website actually looks like. I am not a WordPress expert here, folks. So I'm not going to show you all the tips and tricks for WordPress. But you can see here that we've got a default kind of WordPress website going on here which is pretty cool. So if you were to go to this IP, I think you would be able to see it but that's not very useful, is it? I feel like it's not really a personal blog site until it has a domain name that you can put on a business card, something that's easy to find. So the domain name that I'm gonna use for our website is fields tested. And feel free to put this in your browser right now, fields-tested.rocks. So if you go there, you'll see this hello world message. It's super tiny. So you'll probably can't see it on Twitch but it says hello world, the version 1.0.0 that has a host name on here. And what that is is I created this Kubernetes cluster earlier. I run QTPL, get deploy. You'll see that I have hello web running here and that's what I currently have connected to fields-tested.rocks. So I didn't have WordPress up yet. I just deployed something else. So now I've got to instead of having hello web here introduce my new WordPress site that I'm running in Kubernetes and attach that to my domain name. So now we're starting to get into DNS. And I must say that I am not a network person. It's not my area of specialty but that's fine. There are some things that we should think about those. We're thinking about putting this website. It's always DNS, absolutely. So many challenges that come with it. So there are a few things that we should think about as we start thinking about, we've got our WordPress website. It's running on Kubernetes in the cloud. How am I now going to connect this to that? And what I found that was nice in the documentation, I went to Google Clouds documentation since that's what I'm using. I knew that I needed a static IP for my website. And what that gets me is the ability to connect my domain name to the static IP in DNS so that anyone anywhere in the world when they look up fields-tested.rocks they will find my website. It'll relate back to the static IP that will hopefully never change and they'll be properly redirected to my actual website. So I need a static IP. So what is that going to look like? Actually, this isn't even the page I wanted to show. What do I have? I have them in my bookmarks, I think. I go way down to the bottom. Excuse my Mac bar. There we go. Cool. So here we go. Configuring domain names with static IP addresses. That's something that I care about and want to understand. And it has this nice little tutorial here on how to use, configure a domain name with a static IP address with GKE which is exactly what we want to do. Awesome. So let's see. What is the before you begin section in here say? Visit Kubernetes engine page, create or select a project, wait for API services to be enabled, make sure you have billing. So this is all the pre-work that you need to do to be able to do this tutorial that's in the documentation. We'll need kubectl. Since I'm using the Cloud Shell, I already have kubectl. And then it has us, I install this example. So this hello app example is the one that I have currently connected to fields tested dot rocks. So we're not gonna do this piece. We're not gonna clone down the repo for that. We've already got it running. I just need to know the part about the connecting the domain name to the static IP. So where is that stuff? Here's stuff about exposing our application. If you remember last time, if you tuned in, there was, we talked a bit about services in Kubernetes, which are often how you get access to your applications that are running Kubernetes. That's what we just used our tutorial over here. We saw kubectl get services WordPress and we saw this load balancer type service. So that's exactly the same thing it's talking about here. Using a service, which creates in Google Cloud if you use a load balancer type service, it creates a TCP network load balancer which works with regional IP addresses. I want my website to be available globally. So that seems like it might be a problem, but we also have here use an ingress which creates an HTTPS load balancer and supports global IP addresses. So that seems like it might be more what I'm looking for here. With my WordPress website as I want it to be available globally. So maybe I should create this HTTPS load balancer and use an ingress. So I tried this for the first time yesterday when I spun up this tutorial. It was my first time using an ingress in Kubernetes actually. I've used services quite a bit but I almost never have an excuse to use an ingress. So this is a pretty cool thing for me to explore. So here's the instructions in the tutorial about using a service. And again, this one is talking about creating a TCP network load balancer in the case of Google Cloud with regional IP addresses. And this will be a little bit different depending on what cloud or what environment you're running your Kubernetes cluster in. But one way or another we're gonna use some form of static IP address and preferably some form of load balancer. If you want me to go over why and all of that stuff, please let me know. We talked about that a little bit last time. I won't go into too much detail. So here we've got some G Cloud commands. So it says G Cloud compute addresses create. So this is creating a static IP address in the cloud. That's what I was saying that we needed to connect to our DNS. So I could do it this way and create my static IP address which would be regional and then connect that to a service. And we've got the service definition here and it's got this load balancer IP element where we would put our load balancer IP that we get from this. But I'm gonna skip through the service piece and I'm gonna use an ingress instead. So I'm going to need to G Cloud compute addresses create. Put this over here. It'll be a lot easier to see. Well, probably. I guess it's kind of behind my picture here, isn't it? But it says G Cloud compute addresses create hello web IP dash dash global. And it could not fetch resource because I didn't change the name. I should do that. I'm gonna change this to WordPress IP. Maybe fields tested IP, fields tested WordPress IP being very descriptive and perhaps overly wordy. Let's do that. And so I've now created one. So I should have a static IP now but it's not connected to my actual WordPress deployment yet. So I wanna come back over here and grab this describe command. Sorry if all of the flipping between things is annoying. G Cloud compute addresses describe I'm gonna change that. The name is gonna be fields tested dash WP IP and global. So I wanna see what my IP is here and make sure that it's all up. So it has my IP has some information about it there. It looks good. So our next step is to modify, well, actually to create an ingress to work with our WordPress deployment. So let's look at that. This would be a lot easier probably if I had used something like Cloud Code and Visual Studio Code where I had all of these files from the WordPress tutorial in Kubernetes that I could just refer to and modify. But I don't, I just went ahead and ran them by curling them down. So I'm gonna need to create a new file or do I wanna modify the existing file? Probably doesn't really matter. Sorry, gonna find my, this was my life having too many tabs open. So in this case, it has a service and an ingress. And I'm guessing the service connects to the ingress. Annotations, hello web IP. This is grabbing the ingress that we created. Interesting. And a service name, hello web backend. So we've already got our service defined. Let's see if we can just add this ingress into the same file that we took from the Kubernetes tutorial. So if I do an LS here, I've got a few files in here. The one I care about is gonna be the WordPress deployment. So I'm gonna BI WordPress deployment.yaml. And you can see we've got our service here. So I'm gonna add a line above that. I'm gonna go down and see, yep, it uses three dashes in between. So I'm gonna maintain the same format there. And I went ahead and pasted in the ingress, but this is not set up correctly to work with our WordPress. So let's make it make sense with our WordPress. If I take a look at this real quick. Interesting. I think we can just use the same name that we used for our service, but this time it's gonna be a Kubernetes ingress object. So I don't think I'll get that confused. Name it WordPress ingress or something, right? WordPress. Any ingress? WordPress is probably fine. The ingress for my WordPress, that makes sense. And that's got labels app hello. And instead in our service, we have app WordPress. So I'm gonna include. So this is labeling the actual ingress object in Kubernetes. Oh, if I wanted to find all objects in my Kubernetes cluster that relate to this WordPress deployment WordPress system, then I could look for all objects in Kubernetes that have the label app colon WordPress. So that's why I wanna add this label to my new ingress. It's looking for an ingress static IP with the name hella web IP, but of course we changed that earlier. So that's gonna be WordPress. No, why did we name it? Can't remember what we just named our ingress anymore. I'm gonna exit out of this and find out. Fields tested were WPIP. I was like, it's not WordPress WPIP. That wouldn't make any sense. Okay, so I'm gonna have to do this part again. Insert my three dashes and then I have copied right now, perfect. So again, I've got to change this WordPress for my label and then fields tested dash WP dash IP. And that's gonna allow it to hopefully find our static IP that we're planning to use for our WordPress. And service name is just WordPress it looks like. So I'm just gonna name it WordPress. All the reason I could see that causing problems would be if we're not used for some reason except ingress is there, then it might get confused. Probably a very interesting error to see. So I think we should be all set up here with our ingress. Now I'm gonna have to try run QTPL apply before I did. So I'm gonna run the same apply command. I think this should just update unchanged, unchanged, unchanged, unchanged warning ingress is deprecated. Good to know. There's a lot of interesting work that's been going on with Kubernetes ingress. Maybe I should work with the documentation team to change that tutorial, but that'll be a separate concern. But for now, since we're just doing a demo I'm just gonna leave this as it is. Clearly if we were doing this for real we would wanna consider whatever is coming up with ingress which looks like networking.kates.io slash v1 ingress. So what's being deprecated is the beta version of ingresses in Kubernetes and looks like there's now a GA generally available v1 of ingress in Kubernetes. So if we wanted to use this for real we would probably wanna switch that part which won't be easy to do. Maybe I should just do that as well. vI WordPress deployment should be able to just change this right here, delete that, exit out and run the supply command again and we shouldn't get that warning error validating. Thought it might just work. A node field, okay. So one of the challenges with dealing with deprecation of APIs in Kubernetes something I didn't even expect to talk about today. It looks like the new version of ingress in Kubernetes doesn't have the backend field. I don't even know how we use. That's what we're using to specify the service. I don't wanna figure out how that's working in the new version of ingress right now. I just wanna run my demo tutorial thing here. So I'm just gonna switch it back to the v1 beta one. Don't try this at home. And I'm gonna paste that in and do the same thing with that. Lovely, probably uses labels of some sort to do that now. That was my guess. So I'm gonna rerun kubectl apply. We should see the warning again. There we go. So we should now have an ingress, kubectl get ingress. Nice, so you can see we've got our hello web which has an address. And that's the one that we have connected to fields tested dot rocks right now. So now we've created one for our WordPress. And if my last experience with running the hello web one is any indication, it takes a few minutes for the address to actually come up. So, and then once the address does come up, I'm gonna have to go to my registrar where I registered the domain name that I wanna use fields tested dot rocks. And then I can use their systems to say, hey, make a record in DNS that connects fields tested dot rocks to the static IP address that's going to show up here. And that takes 30 minutes to propagate for you to be able to use that anywhere in the world. So we're not actually gonna see this WordPress site on fields tested dot rocks by the end of this. But if you follow me on Twitter, I'll probably post on Twitter and be like, hey, we did the thing. It's up on fields tested dot rocks right now. I've been debating whether or not I should actually use this website. I mean, I could. And actually spin up a fields tested rocks website for fields tested. That could be pretty cool. But anyway, so at this point, what else do we have in this example? This has to apply the resource to the cluster. We did that a little bit differently. Keeps ETL apply and we used our customize file, which we didn't go into a lot of detail on, but it was how the tutorial in Kubernetes did their building of all of the pieces in our WordPress application in Kubernetes. And so we did that, we checked out our ingress and then let's see if that's up now. I won't see it yet. I wonder if it's having trouble connecting to the, if I messed up my definition in here. Fields tested WordPress IP. The bad should work. It's going to take a few minutes last time. So that could be all of this. And I could also run gcloud compute addresses, describe the fields tested WordPress IP just to make sure this still exists, which it does. Yeah, I don't know. Oh, it's not up yet. If it were up, we could go and check out our WordPress on our ingress. As it is, I can at least see it on the same service. Yeah, which has an external IP here, which is how we have it up right here, which should still be working and everything, which it is. So that's pretty much all I wanted to show you all with running a personal blog on Kubernetes in terms of how you would actually do it. And the reason I wanted to do this before, if you've seen any of my posts about it is that there was a post on Twitter comparing running a personal blog on Kubernetes to building a sandwich using Power Tools. And I hope that you all have started to see how those two things kind of connect here, where Kubernetes gives you a lot of tools that really make a lot of sense for enterprise use cases if you wanna run your own websites, but there are a lot of hosting services out there that just give you this piece, just the, well, technically not even this, just the dashboard to WordPress, give you the access to WordPress. And you don't have to worry about running it, you don't have to worry about this ingress and static IP business. There are a lot of websites that just smooth all of that stuff over for you and basically do all the things that I just did. So it's a great way to learn about Kubernetes and some of the things that it can do well, but it doesn't make a lot of sense to do generally on your own. If you just wanna run a personal blog, say you're a restaurant that needs a personal website or something, probably don't wanna deal with all of these pieces, but if you're learning, it makes a lot of sense. So one thing that I could do now if people are watching and want to is to now explore what other things we should do with this. Cause I just ran my database in Kubernetes. I didn't put any of my code into source control. There's probably more that I could explore with this ingress and learn about, which I wonder if that is up. Nope, I probably get something wrong there. So I'll have to go and explore that stuff later, but I don't wanna deal with it right now. So we could start to explore these things. What are the topics that we would like to explore more with this WordPress application running on Kubernetes? Like I said, I think some of the storage projects in the CNCF landscape would be good ones to explore here. Yeah, and source control thing. Those would be some of my suggestions. Do you all want to try to map that out? Maybe take a look at the Cloud Native Computing Foundation landscape and see what other projects we think might make sense of this or are people kind of done? We could kind of finish up for the day. We did our thing, which was running a personal website on Kubernetes and I know how to get it connected to fieldcestive.rocks, but it's gonna take a bit. So I'll update that. Not seeing any movement in the chat, so I think I'm gonna stop here for today. Thank you to everyone who joined. I hope that you learned something fun and I'll see you all around the internet. And don't forget, KubeCon registration is open now, by the way, something that I meant to mention. I should have put in my notes at the beginning of the show. So if you want to register for KubeCon North America, definitely check that out. All right, I'll let y'all go. Thanks for joining today and be sure to check out cloudnative.tv for the rest of the week and next week to see some different shows. Tomorrow is raw code and pop. I'm sure they'll be awesome. See you on the internet.