Sometimes, you need to dig a little deeper into the product you’re working with in order to solve an issue you are facing, or to find out more about how it works merely to satisfy your curiosity. As some of you might know, I definitely fall into the last category!
This post is part of a Series in which Robert Jan de Groot and I explore the inner and hidden parts of Rubicon Red MyST Studio which might come in handy at times.
In this blog, we’ll show you how to get to the parts of Rubicon Red MyST Studio which make it tick. We’ll also try to name the components and explain how the parts work together to make your day better.
High Level Architecture
MyST Studio consists of a few components, some of which are optional.
- MyST Studio
- Database
- Continuous Integration Server (optional)
- Binary Repository Manager (optional)
Whether or not the last two components are optional, depends on whether you want to do Release Automation with MyST Studio. If you do, they are both required.
Our current client doesn’t use MyST Studio for their Release Automation, and therefore does not have the extra components available for MyST.
The relation between MyST Studio and the Database is very straightforward: all data resides in the Database, and MyST Studio just connects to it to do its CRUD-operations on the data. Nothing too fancy there!
Agentless?
MyST Studio claims to be an agentless application, which in this context means you do not need to install an agent on every single machine/host you want to connect to with MyST.
This means MyST has a completely different setup from the likes of Puppet and Oracle Enterprise Manager, which both work exclusively with hosts with an installed and running agent. (They’re both conveniently called Agent as well.)
MyST does not require you to install an agent on the host, it’ll actually do so itself!
The major difference here is that this MyST Agent only runs during the execution of an Action on that host, and it is shut down afterwards.
This means no additional resources are being used on your hosts when MyST is not actively execution an Action on a host, which is very convenient.
Also, you don’t need to worry about upgrading or downgrading this MyST Agent whenever you’re using a newer or older version of MyST Studio: the application will take care of this itself.
The Agent
Obtaining the MyST Agent to rummage around in it can be done in two ways:
- Copying it from a (target) host in your network
- Pulling it from MyST Studio
Copying from a host
MyST Studio puts the MyST Agent on the host where the AdminServer of your OFMW domain resides. It does so on a location which is user configurable. This configuration can be found in your Platform Blueprint and/or Platform Model as a Global Variable.
The default is /opt/myst.
So getting the MyST Agent might be just as easy as punching in this command:
tar -cvfz ~/myst-agent.tar.gzip /opt/myst/
After this you’ll be able to pull the gzipped tar from the host using scp or just using it on that host as is.
Pulling from MyST Studio
We are assuming the default and recommended setup: with Docker and Docker Compose.
The yaml dictates a lot of things, amongst which is the name of the containers, and we’ll happily assume you’re also using this.
After logging on to the host where your Docker Container lives, you’ll be able to pull the pre-packaged MyST Agent from your running Docker Container with this command:
docker cp myststudio_web:/usr/local/tomcat/conf/fusioncloud/agent/myst-impl.zip ~/myst-impl.zip
This will copy the file myst-impl.zip from a certain location on a running Docker Container with the name myststudio_web to the home directory of the user you are running the command with.
How does the Agent work?
Disclaimer. The information below is compiled based on my personal experience with the MyST Agent, and is not based on any official documentation. Therefore, the information presented here is likely to be incomplete, partial, outdated or even plain wrong.
The core functionality of the Agent resides in a jar-file, aptly called myst-core.jar.
This is also where the majority of logic can be found, and almost all information regarding the computation of value amongst Platform Blueprints and Platform Models is done.
Callouts are made to either ant-based or Jython-based MyST Actions, which can be found in /lib/targets/.
Also, a Go-binary called apply-* lives inside the zipped MyST Agent at /lib/agent/, which seems to be doing the majority of the work required to update an environment to its new state. Although, I cannot be sure about what it does, as I cannot decompile it and check out the contents.
We hope this post helps you to understand the product MyST Studio a little better!
Knowing which parts do what, and how to find out *exactly* what is does has been a tremendous help at our client, and we hope it’ll bring the same to our readers.
Be sure to let us know by leaving a comment below, or via @maartentijhof.
