Using Relay’s flexibility to turn scripts into permanent tools
Getting started with Relay
Relay’s inputFile capability is handy because it allows you to use familiar programming languages to get custom solutions working quickly. Using an inputFile with Relay is as easy as writing a script in bash, Python, or Powershell, and storing it in a remote Internet-accessible repository like GitHub. Let’s see how Relay enhances our daily driver skillset to solve problems quickly and reliably with minimal code.
In this blog post, we’re going to use an inputFile attribute with a Relay step to solve the very real problem of replacing a pair of dependent services whose cost has eclipsed their value.
Microservices are hard
Microservices expire, get replaced, and are upgraded at differing cadences. Take a look at the current Periodic Table of Devops Tools to get an idea of the buffet of options on offer. Combine all these options with custom solutions and integrations and you can see why no two organizations’ tech stacks are alike. Often, you’ll find a situation where, given a set of interlinked services, one service needs to sunset long before the other, which is exactly the scenario we are going to work through here. Relay to the rescue!
In the situation I’m about to describe, my team needed to quickly deprecate an upstream service that fed data to other downstream services that were critical to provisioning vital cloud infrastructure on demand. The integration between the services was a couple thousand lines of custom code that had long since been abandoned by the original development team. Unsurprisingly, our team had little appetite to re-write the integration completely. The problem reminded me of my brief foray into gardening during which I’d planted several plants too close together, leading to root system entanglement that I wasn’t sure how to fix (and the devastating loss of my precious few jalapeños to some spicy squirrels!). Ultimately, using Relay’s strengths, we were able to replace the service and the integration entirely.
The following example is the total YAML needed to build a Relay workflow step that uses our custom Powershell script.:
Turning scripts into Relay tools
That relatively small amount of YAML does the following:
- Specifies a unique name for the step for reference inside the Relay workflow
- Defines environment variables and optional parameters to be passed into the step runner environment
- Identifies a remote script location from which the Export-API-Data.ps1 script is retrieved and run using the Powershell image
That is the sum total of the Relay config needed to use our Powershell code stored as a script in Github. The magic here is the scriptUrl attribute, which allows the retrieval of a previously written script from an accessible Internet location. Continue to write scripts the way you do everyday; when you are ready, the scriptUrl attribute allows you to easily turn those scripts into powerful long-term tools.
Relay also saves time and anguish by handling secrets management right out of the box. The Env: section of the config maps secrets to runtime environment variables that the script can consume. The parameters section exposes a toggle-able switch enabling you to run this Relay workflow on-demand in a debug-only mode, again passing this option into the script at runtime as an environment variable. When set to True, the script produces nothing but log output for easy troubleshooting.
And that was it — a custom integration of nearly two thousand lines of code became a Relay workflow that runs an easily modified Powershell script several orders of magnitude less complex than the original integration.