 The following is a Coderland presentation about our latest attraction, the Reactica Roller Coaster. Hello! This is Doug Tidwell for Coderland. In this video, we'll finally deploy and run the Reactica code. Our starting point is that you've cloned or forked the Reactica repo whose URL is on your screen. This contains all of the code, of course, along with shell scripts that install everything and deploy everything for us. To get started, you'll need a copy of Minishift 1.33.0 or higher on your machine. You can get that from this URL, or if you're a Red Hat Developer Program member, and why on Earth wouldn't you be? You can get a copy of the Container Development Kit from yet another URL displayed beneath my chin. You'll also need Curl, Python, and Maven version 3.5 or higher, and you should have some healthy snacks nearby, along with maybe a good book, or some hiking boots. Scripts build a large cluster on your machine and install enterprise-grade middleware inside it so they take a while. The good news is you just run them and they work. To make sure we're starting at the same place, go to the RHTE demo directory and run these commands. Minishift Profiles set our RHTE vertex demo, Minishift Stop, and Minishift Delete. If Minishift asks if you're sure you want to delete the cluster, say yes, we're starting from scratch here. Finally, type setup-deploy.sh and reach for those snacks or that book or whatever you'd like to do while the script runs. It builds an OpenShift cluster that uses 8G of RAM and 3 virtual CPUs, so you'll want to shut down as many other things as you can. Obviously, we're not going to show things in real time in this video, but the script first creates the RHTE vertex demo cluster, gets it up and running. When that's done, it installs Red Hat DataGrid and waits for it to be ready, and finally installs Red Hat AMQ and waits for that to be ready as well. On my system, that took about 18 minutes. In the spirit of full disclosure, the script should run successfully, but occasionally it may time out, waiting for the DataGrid or AMQ components to be ready. If that happens, it shouldn't, but if it does, run setup-deploy.sh again. The script will skip past the things that are already running and finish deploying whatever didn't deploy before. In dozens of tests, that happened to me once, but I wanted to mention it as a slight possibility. Once deploy.sh is done, switch to the setup directory. You can configure the parameters of the coaster. There is a file named application.yaml. That contains values that configure how often new users get in line, how long a ride on the coaster takes, and how many people can ride at once. If you like, you can edit that file. Whether you edit the file or not, run create application config.sh. That creates a Kubernetes config map used by the Reactica components. If you want to change it later, type oc edit config map reactica-config. Moving right along, it's time for the final step. From the setup directory, run deploy application.sh. This builds and deploys your code. This takes a while as well. On my machine, it was about five to six minutes. When you see that everything is in the ready state, you're good to go. Now you need to access the billboard UI. Type oc get routes to see the routes into the cluster. From here, you can see the address of the billboard component. Copy and paste that URL into your browser, and you should see something like this. Initially, no users are being generated. To fix that, switch to the ride admin panel and click the start user generation button. That tells the users and rides component to start creating users. Go back to the ride status page, and you should start to see some users appear. At some point, a new ride is created, which puts some of those users on the ride. Not long after that, those users transition to the completed ride state. Notice that users change color as they move through the line and ride the coaster. We encourage you to play around with this. Change the configuration with the oc edit config map command. Let 20 people ride it once. Have a new user get in line every three seconds. Make the ride last only 20 seconds. As you make these changes, you should see different results in the web UI. Before we go, we'll do one more thing to illustrate the resiliency of our reactive system. We'll go to the command line and look at the deployment configs in the system. Now we'll use the oc scale command to scale the event store component down to zero. If we look at the web UI, no new users are being added to the queue. However, if we look at the log for the event generator component, we can see that users are still being created. Notice the names here, including our dear friends Shy Iguana and Snap Dragon Sloth. If we scale the event store component back to one, those two users and probably several others will make their way into the queue. Switching back to the web UI, we can see those users are indeed in line. Event generator put data into AMQ and it didn't get lost even though the component that handles that data was shut down. When event store came back online, it processed all the data and the system went on. With that, we'll bring our discussion of the Reaktica roller coaster, reactive programming and vertex to a close. This is a complete complex example that shows you how to build a reactive system of microservices that use asynchronous data passing to get work done. You can find more resources on the technologies and products we've used here at the URL below. Thanks so much for watching. We hope you've enjoyed this content. As always, we'd love to hear from you. We're coderland at redhat.com. For Coderland, this is Doug Tidwell saying may all your bugs be shallow. Cheers.