The IBM Stock Trader operator, part 1: Usage
Learn how to use the umbrella operator for the IBM Stock Trader sample
Note: This article is now somewhat outdated. What you do once it appears under Installed Operators is the same, but the current instructions for getting it to appear under Installed Operators are at https://medium.com/hybrid-cloud-engineering/portability-of-applications-across-kubernetes-distributions-part-1-9b8a5eae4890. That article also covers using it on Kubernetes distributions other than OpenShift.
In an earlier article, I discussed the “umbrella” helm chart I created for my cloud-native sample, the IBM Stock Trader. This treated the sample as an application that you installed and configured as a whole, rather than doing so microservice by microservice. I’ve recently turned that into an “umbrella” operator that integrates deeply with version 4.3 or later of the OpenShift Container Platform (OCP). Here we’ll look at how to use that to deploy and configure the sample; in part 2, we’ll discuss how I developed this operator.
Since I’ve not yet integrated this with an operator registry, such as Red Hat’s Operator Hub (I don’t think such a sample belongs there), for now users will need to clone the Git repo and run oc create -f against several yaml files (this directory structure, and the files referenced below, are what the operator SDK generates; much more on that in part 2):
git clone https://github.com/IBMStockTrader/stocktrader-operator
cd stocktrader-operator/stocktrader-operator/deploy
oc create -f crds/operators.ibm.com_stocktraders_crd.yaml
oc create -f service_account.yaml
oc create -f role.yaml
oc create -f role_binding.yaml
oc create -f operator.yaml
oc create -f olm-catalog/stocktrader-operator/0.1.0/stocktrader-operator.v0.1.0.clusterserviceversion.yamlThe last of those is only needed if you wish to use the integration with the OCP console. Even without it, you could create a new instance of the sample via the CLI. For example, you can edit and pass it a file with the answers to the questions that would have been shown in the console UI, such as the provided example, via oc create -f crds/operators.ibm.com_v1_stocktrader_cr.yaml, which will result in pods being created for each desired microservice, with a prefix of the name of the Stock Trader instance, such as pods named demo-trader, demo-portfolio, and demo-stock-quote for an instance named demo. You could also see all of your installed instances of the sample via oc get StockTrader, or see the details of a particular one, such as the demo example just mentioned, via oc get StockTrader demo -o yaml. You can also delete all of the objects created by the operator (the various deployments/pods, config map, secret, route, etc.) at once, via oc delete StockTrader demo.
Let’s spend the rest of this article focusing on the integration with the OCP console UI. The commands in the box before the previous paragraph will deploy the operator (from DockerHub) as a pod in your namespace, and make it available under Installed Operators for your namespace. Note I used the OCP 4.3 beta in IBM Cloud for this work.
If you then click on IBM Stock Trader application, you’ll get the page showing all of your installed objects of type StockTrader. Of course, there aren’t any at first, so you want to click the blue button to create one.
That will take you to a page where you can see yaml for all of the settings available for an object of type StockTrader. You could edit this directly, if you prefer. But I like to use the form UI instead (which was the part that took me the longest to develop and debug). Click on the Edit Form link in the top right.
Now you will see that there are various expandable sections that you can fill in, depending on which features of Stock Trader you want to use.
For the most part, you can accept the defaults and get basic functionality. The one big exception to that rule is that you MUST supply the fields for the JDBC database, which is where the portfolios and their stocks are persisted. Expand the Database twisty. In my case, I’m using a DB2-as-a-Service hosted in the IBM Cloud (but I could have just as well installed my database locally into this cluster).
The other sections are optional; for example, you’d only fill in the MQ and Twitter sections (and the Messaging and Notification-Twitter microservice sections) if you want a message to be tweeted each time your loyalty level changes. Note you would need to fill in the ODM section for the app to be able to determine that loyalty level (otherwise the level will always remain unchanged at Basic, but otherwise the app will work as expected).
Likewise with the Kafka and Mongo sections (and the Trade-History microservice section), only being needed if you want to keep track of the original cost of each stock, so that the return-on-investment calculation (comparing current stock values to their values when purchased) can be performed and displayed. If you don’t care about such extra bells and whistles, just ignore such sections.
Once you’ve filled in your desired values and hit Create, you’ll see a new entry on the page for installed Stock Traders. Click on that to see its details. In particular, I like its Resources tab, which shows all of the Kubernetes objects created across the various microservices that comprise the Stock Trader application. These include Deployments, Services, Ingresses, Routes, HorizontalPodAutoscalers, ConfigMaps, and Secrets, depending on the options selected on the form. There are 20 such generated resources in the example below (some are cut off in the screenshot).
You can of course click on any of these particular resources to see their contents. For example, many of the values entered on the form end up in the config map that gets generated, called {name}-config, such as demo-config. There are 34 fields in there, shown alphabetically (with good defaults where possible), though most got cut off in the screenshot.
Sensitive fields, generally related to login credentials for the various services used by the application, are stored in the secret that gets generated, called {name}-credentials, such as demo-credentials. There are 21 (alphabetized) fields in there, which are base64-encoded (whose values can be seen/edited by clicking the Reveal Values link), though most are cut off in the screenshot.
Each of the microservices have their own Deployment (and associated Pods), Service, Ingress, Route, an HPA generated (depending on your options selected). You can also view these the old-fashioned way, such as by clicking on Workloads->Deployments in the left nav of the console. The name for each will be prefixed with the name you gave for the overall Stock Trader instance (such as demo in this example — I’ve filtered the list in the screenshot below to just those starting with demo).
Let’s launch the UI for our newly installed application. From back on the Resources tab (or via Networking->Routes in the left nav), click on {name}-trader, such as demo-trader. You’ll see the URL for the generated route.
When you launch that, initially you’ll see the “Welcome to Liberty” page; you’ll need to click in the browser’s address bar and add “trader” to the end of the URL and hit Enter to see the application.
Congratulations, you have used the operator to install and configure and access the IBM Stock Trader application! Stay tuned for part 2 to learn how to develop such an operator yourself.
