Feedback is important in any creative process. When sculptors are commissioned to create a massive bronze statue, they don’t just acquire a large chunk of bronze, melt it down, form it up, cool it off and hope their patron will be satisfied. Rather, they use a maquette, or a smaller model, to get feedback (and more importantly customer approval).
In a similar way, when building environments with Torque, you can gather feedback to diagnose your sandbox before the creation process is complete. Let’s take a look.
Within the blueprint, define a blueprint debug section:
And within the application, define an application debug section:
Why define it in two places? The blueprint is the top-level place where your sandbox can accept outside connections for debugging / troubleshooting purposes, and the application. For example, you may have a blueprint that allows debugging and only one of your two applications actually allow you to connect for debugging.
The basic workflow looks like this:
Custom Debug Tool
One of my favorite things about Torque (and IaC field in general) is that it’s fully customizable and sharable. Take, for example, a debug application I created called logconsole.
The important parts of this application are the admin.py
It uses a very simple form to get path information from the user:
What does this do?
I’ve included this application in my Jenkins blueprint, so, let’s instantiate it:
Notice that the artifact to be deployed will be the logconsole application’s binary. When the sandbox is up, notice that logconsole is a Quick Links item:
Click on the logconsole link (from the above example it is http://22.214.171.124:8000) and you’ll see the “Hello World”(see below):
If you append /form to the end of , you’ll see a simple textbox:
You can enter the path of any log you wish to see, such as /var/log/messages. Click “Submit” and — BAM! You’ll find a (no need to ):
That’s just the beginning. Open a PR against my repo and we can make this little debug tool a cool mini-!
The power of Torque
Cool, huh? And it’s all possible with Torque, a powerful, Environments-as-a-Service platform that uses Infrastructure as Code to provision infrastructure that works for your existing process. When you use Torque, you can securely share infrastructure provisioning with a group, focusing on designing your environment rather than worrying about what cloud to use or what infrastructure automation to use. It picks up where traditional IaCs and other CMPs leave off.
I’d love to see the cool stuff you can do with Torque within your CICD pipeline. Share your results in the comments below.