Reactive programming tutorial: Deploying Reactica

Tutorial: Reactive programming and Eclipse Vert.x

This is the fourth of a four-part interactive tutorial on reactive programming and Vert.x. The tutorial can be viewed in full at developers.redhat.com/coderland/reactive/.

The reactive system built in this exercise represents data about the Reactica roller coaster at Coderland, an imaginary theme park that showcases modern technologies and techniques. The Reactica system contains multiple components that use Red Hat AMQ, Red Hat Data Grid, and the Vert.x event bus to pass data asynchronously. The end result is a web UI that calculates the current wait time for the coaster based on the number of people in line, the length of the ride, and how many people can ride at once.

The web UI also displays a list of users. That includes park guests who are still in line, guests who are currently on the ride, and a few of the guests who have already ridden the coaster. The entire display is driven by a sophisticated infrastructure that illustrates the power and flexibility of reactive programming.

Your assignment: Build the web UI that shows Coderland guests how long they'll have to wait before experiencing the awesomeness of the Reactica roller coaster.

Repositories

• The Reactica roller coaster: github.com/reactica/rhte-demo
• A Vert.x starter application: github.com/redhat-developer-demos/vertx-starter

Articles

• Reactica Part 1: An introduction to reactive programming and Vert.x
• Reactica Part 2: Building a reactive system
• Reactica Part 3: A reactive system in action

Other Resources

• Free book - Building Reactive Microservices in Java
• The Reactive Manifesto
• Andre Staltz's reactive programming tutorial

Transcript

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 [github.com/reactica/rhte-demo]. 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 [github.com/minishift/minishift/releases]. Or, if you're a Red Hat DeveloperProgram 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 [developers.redhat.com/products/cdk].

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. The 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 profile set rhte-vertx-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 8 GB 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-vertx-demo cluster, gets it up and running; when that's done it installs Red Hat Data Grid and waits for it to be ready; and finally, it 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 data grid 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 ConfigMap used by the Reactica components. If you want to change it later, type oc edit configmap 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 5-6 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: [web UI on screen]

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 configmap reactica-config command. Let 20 people ride at once. Have a new user get in line every 3 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 deploymentconfigs 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 Snapdragon Sloth. If we scale the event-store component back to 1, 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 Reactica roller coaster, reactive programming, and Vert.x 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 [developers.redhat.com/coderland/reactive/.

Thanks so much for watching, we hope you've enjoyed this content. As always, we'd love to hear from you; we're coderland@redhat.com.

For Coderland, this is Doug Tidwell, saying May all your bugs be shallow. Cheers.