 Welcome again. Here is the last talk of today from the analysis testing and automation track. It is called Up Your Game with OpenShift and it is presented by Manuel de Voel. It's yours. Yeah, thank you. Thank you for that introduction and welcome everybody to the last session of today. I hope it will be at least a bit fun, but if not there is a game in it, so probably that game will be at least fun. So you will see. My name is Manuel. I'm working as an SRE at Red Hat in the OpenShift dedicated team. We are running basically OpenShift clusters for our customers, both Red Hat internal customers, but also external customers. And in addition, why I got in touch with that topic at all is I'm writing a book about that operating OpenShift and for that, I was digging into the different possibilities that there are to build and run software in OpenShift. So if you end up liking the game and you would like to see how we deployed it in all the strange ways you can think of, that book might be something for you. You can take a look at my Twitter. So you want Mr. Lee State if you want. On this slide, I have all image sources so you can scroll back to this slide if you're interested in where I got those images from. And now let's get right into it. So first let's set a bit the scope of this talk. Do I expect you to be a proficient game developer? For sure not. But should you expect me to be a proficient game developer? Also probably not. As I said, I built this game mostly out of curiosity for how game development works and because it was a great example for something that you can build from scratch and you can deploy to an OpenShift cluster. You can build multiple services for it and deploy them. And it's very fun to create a game using open source technology. And games are not something that you typically find deployed to an OpenShift cluster. There are more like business applications, small web services deployed. And so it's something pretty unusual to deploy to an OpenShift cluster. And last but not least, it's also fun while you think about how to deploy something that you can actually play a game while you think about it. The game I built doesn't require such a crazy gaming machine and it may look a bit familiar. It's actually running on one of those OpenShift dedicated clusters and it should be able to run on your phone. So that should have enough compute power for that. So while I was working on that, I wondered how do people nowadays even create browser games like some game that is running in the browser in the end? How does the workflow of game development look like? And I don't know how the gaming industry actually works, but I know how I would solve this problem. And I would solve it in a similar way that I solve other software deployments and that is with a CI pipeline with a continuous integration and deployment pipeline. It turned out that there are a handful gaming engines and I chose one gaming engine which seems to be a bit familiar, seems to be a bit more famous in the open source gaming community. And that's the Godot game engine. The Godot engine allows you to build games with what you see is what you get, scene editor and you can create 2D scenes and 3D scenes and so you can design your UI and then you can write the actual logic of the game using the Godot scripting language or even other languages that are available. And then when you build that game, you have only to build it once and then you can compile it to Linux, Windows and Mac binaries also to mobile apps and you can also make web apps out of them which are then running using WebAssembly and WebGL. And that's what I did for the small game. So now let's see what it means to change that game and to deploy that game to an OpenShift cluster. So we'll actually do a change now live to that game while I am deployed to the cluster. So during the talk you should see the UI change a bit. For that I'll switch to the Godot interface here. I hope you can see that. And here is the interface and the change that we are doing is we will make that snake that's currently just red and we are hunting like blue apples. We want to make that a bit more DEF CON themed. So we'll change the color of the snake from red to purple and the target we will change from that blue bubble to a DEF CON themed target that we want to collect for that. There is already everything prepared. We just need to change in that script here the tiles we want to use. That should be an easy change. Please don't judge me by the amount of global variables we have here. It's really the first game I ever built with Godot. Okay so now you can see it has the DEF CON theme and now we want to deploy that continuing the talk to OpenShift. For that let's first see how that change actually looks like from a Git perspective. So that game is a Git repository and we can see that so far we only changed that script and if we now use Godot and export the game to HTML5 we can do that. We can export the project here to HTML5 and then it will create an index.html file alongside some web assembly files that we can then put on a web server. So we can do that export here and when we then go back to Git we will see that there is the export here. But now everything on OpenShift is running in a container so how would we get those changes into a container? Of course we could create the container and copy everything just into the container but that's not how I imagine a good deployment pipeline for a game that a developer would need to commit the compiled game basically. That's the binary game to the Git repository so we can then build a container out of it. Instead we would want to commit only the source code, the script that we changed and the CI should build the game and deploy that new game to OpenShift. How do we do that? The first thing we need is we need something that can build the game without running that Godot game UI and luckily Godot has a headless version available where you can just run a command to export the game to whichever target you want and that's what this command here does in that docker file. There is even a container image available which we can use which contains everything we need to do that export. In this two-stage docker file here in the first stage we're compiling the game and in the second stage which is derived from Nginx a web server we can just copy the exported game from the first stage to the second stage and have the game available in the outcome container image. That means Godot doesn't need to be available in the game container that we built but just in the compilation container which makes it smaller and doesn't have so much overhead things that we don't need in it. Okay so let's do that. We can go back to the terminal and you can see that there is this docker file here and we can use that docker file now to build a container. So we use podman here to build a container and also to run it. That container is running so we should now be able to see the game in the browser and there we go. There is the new game with the new defcon theme. Great. But still we wouldn't expect developers to do that right. We don't want them to build the container on their machine and then deploy that to OpenShift or commit it to a registry and then something else would deploy to OpenShift where are my slides. What we want is some CI should do that run that docker build for us and that's the icon be running on OpenShift as well. There is built-in infrastructure in OpenShift that you can use to build such containers. But we want to go one step further now. We don't want our go.developers to even think about building a docker file. We want OpenShift to create only from the source code of the game the game container image and that's possible using the so-called source to image feature that's included in OpenShift. With source to image, OpenShift is even able to detect from a Git repository or a folder which kind of programming language is used and get the right builder to compile and run the application that we're building. So for example if you have a Git repository with a go.mod file OpenShift will detect that this is a program written in go and will use a builder image for building go applications. Source to image supports a variety of languages like Ruby, Node.js, .NET, Go, Python, Java and PUL. I couldn't find out if I can use the Java logo so I ended up using that cup emoji. Sorry for that. But there is one programming language missing here and probably you have already guessed which one it is. It's go.of course source to image out of the box doesn't support go.dot. So let's see what it means to create a builder for source to image for go.dot. The builder itself is a container image, the so-called builder image. So that's what we need to build now. It's an and the game container that source to image will build as output is then based on that builder image. So how do we build that now? That's a different Docker file and that's what you see on screen now. In that Docker file we have again a web server which can then run the game. So that's what we install here, the go.engine and then up sorry that's the go.engine that we need to compile the game and up here is the web server that we need to run it. So there you can already see the difference between the two-stage Docker image. For this builder image we need everything to build but also to run the game. And in addition we need to provide scripts which are then used by source to image to build the container image by telling it which script should be used to run the game and which script should be used to build the game. And this is how the scripts look like. They roughly compare to the two stages in the Docker image. The left one is the assembled script which is used to build the game and the right one is the script which will be the entry point of the container. So that will run the game. Okay, so that's what we'll do next. We use that Docker image, that Docker file and build a builder file for go.games. So let's stop that here. Okay, so first of all we're connected to the cluster and we'll create a new project here so I don't interrupt your gaming experience. I see already some high scores popping up here. And in that new project that I just created we will now create a new build and now I need to go to the right directory. So there is the Docker file for the builder. Again, this is we will now build that image and I can do that right now but this is not building the game. It's only building an image that will be used to build the game and this can be distributed independent of the game. We can provide that image once and then game developers could build games using Godot, commit them and OpenShift could figure out how to build that. We won't wait until this is finished because this takes too long but instead we will now use one that is already available and that is in the namespace that you're currently using to play the game. So let's switch to that project here where the game is deployed and here you can see a build config for the game that we use and as you can see this is based on our builder image. So this is build using the S2I builder image that we provided here. What you can see as well here is a Wepo URL that I use in GitHub to automate the deployment of the game later on. So what we will do now is commit the changes to the script to the good repository and then watch them being deployed to the OpenShift cluster. For that, of course, I need to go back to the game directory and now I want to commit only the script and we push that to the Defconn branch. Okay, those changes are in now and now we should be able to see when we take a look at the builds, a new build which is now running, compiling the new version of the game that it just deployed to the good repository. And this build finishes. You can follow the log so we see when that's done the rollout of the new game should start. So here we already add the pushing state so the container image will be written to the cluster internal registry or not. Okay, it was a pull state, not a push. Now it's pushed to the registry so what we should see now is when we take a look at the deployments we should see that there is for the game which is called S3E, there is currently the rollout happening of the new version of the game. So if we now go to the browser, this is the old version and when we refresh here now we should see that the deployment has happened and we are now using the Defconn theme here. Okay, so let me switch back to my slides. Now that has happened but probably it's not all that you need for your game, probably you have a need for a more sophisticated pipeline and luckily OpenShift also comes with a full flash pipeline system which you can use to run all arbitrary kinds of pipelines like including running unit tests, running integration tests, the build, the deployment, deployment to different targets and you can even use the pipelines to verify PRs on GitHub for example before they are actually merged in. So this is all included with OpenShift. You can install Tecton by installing the OpenShift Pipelines operator from operator hub on your OpenShift cluster and then you will get a fresh Tecton deployment. The pipeline definition in Tecton is based on custom resources. So Kubernetes resources are leveraged here for everything in a Tecton pipeline. That's the pipeline definition itself. That's a single instance of the pipeline which is called a pipeline run. What makes up the pipeline, so different tasks in the pipeline, the event listeners that are triggered from GitHub for example and also triggers are custom resources. So you will end up when you write a pipeline in Tecton you will end up writing a lot of YAML and a lot of different resources but in the end you have also some declarative configuration that you can deploy to the cluster as you would deploy for example the deployment. So the last thing I want to just quickly show you the user interface of Tecton in the OpenShift console. So this is how the pipelines look like and as you can see there has been as well a build triggered from GitHub when we pushed to the central repository and that pipeline run was green and you can see the name of the custom resource of the invocation of the pipeline and you can see the pipeline itself and when we click on that pipeline run you get an overview here and you can even dig into the locks of that pipeline run. There's also a CLI tool for Tecton but I think as an overview of what you can do with it this is like the solution if you want a full-fledged CI. Okay so summing this all up when you have a simple use case like you have a simple application that's supported by SCI or a similar use case, SCI or source to image may be the right choice. However Dockerfiles provide some level of abstraction for building and running an application so you can use them with your container engine to run your application or your game locally and then you can use the same file to deploy it to a cluster and also they allow the two-stage builds which is a bit more complicated when you use source to image and in the end if you need a more sophisticated pipeline including the build test and deployment and probably to different environments or tests before merge probably Tecton is what you need to build your full-fledged pipeline. I hope that this allows you to like decide which way to go but the good thing is all this is already included with OpenShift. Okay so I see there are some people have played the game so let's take a quick look at the high scores here and okay I see a lot of scores and a lot of people have outperformed me. Dan doesn't count he's a colleague of mine so congrats I hope you enjoyed the talk or at least enjoyed playing the game. Thank you Manuel. I originally wanted to party over the weekend but it seems that I will spend time with Dockerfiles and OpenShift dedicated and I will have Pierre at home. This is very inspiring actually you know as of now we do not have any questions. I can I can say that I can maintain one game and when the deployment was meant to happen it I first need to pray you know make sure that everything works perfectly then I spent few hours and then it worked and this is this looks like a breeze so that's this is this is the future. So I don't know how like deployment of games actually works I hope they have something that makes sure no bugs go to production but who knows. Yeah all right do we have any questions oh yeah there to find a link to the game because it was only on one slide so maybe you can put it to the chat. Sure I can put the link to the chat again I will also turn down that cluster today your latest tomorrow so if you want to play do it now or you can also I can also share the link to GitHub so you can get it from there. Seems there are no questions so thank you a lot for the presentation Manuel and yeah enjoy your day and this was the last session of today or I believe for the conference so we will see each other tomorrow. Yeah see you tomorrow enjoy evening. See ya. Bye bye. Bye.