The following is a Coderland presentation about our
latest attraction, the Reactica roller coaster.
[screams]
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 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 [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:
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.