As our cloud server fleet grows, the DevOps team is increasingly nickel-and-dimed with small requests and troubleshooting tasks, for which we sometimes needed to RDP into instances. Indeed it’s for this reason that my Connect-RobotArmyv2Group and Connect-EC2Instance scripts were put together. But it’s far from ideal. For one thing, RDPing into individual instances is very Anticloud indeed.
But, we think we’ve got it under control now, and as per usual, it’s down to our trusty multi-limbed friend, OctopusDeploy.
Everybody knows that OctopusDeploy is an orchestration engine for deployment. You configure environments and roles, and then piece together a workflow for a deployment, and then you drive that workflow to get your code shipped out to instances.
But not every Octopus user is also aware that Octopus and its tentacle armies make a fantastic engine for running arbitrary PowerShell code across your entire fleet, or a subset thereof.
Enter the OctopusDeploy Script Console, an oft-overlooked feature but one that’s just become my new favourite thing.
Go click the “tasks” menu, and look in the top right. There’s an unobtrusive little link marked “Script Console”.
Click it and you get a UI much like the one below. Here we see an example of me reading back a CloudFormation Init log to see what went wrong in a provisioning run after making a small change.
Any output from the script is written back to the log. Better, when a developer or PM comes to us now for troubleshooting info, we send them back to Octopus with a code snippet, thus empowering them to do an increasing number of small housekeeping and troubleshooting tasks for themselves.
Naturally, at this point, our friend Spiderman makes an appearance
Yes, Spidey. You’re right in saying this is insanely powerful and shouldn’t be used lightly. Take, for instance, the ability to run the following against a production web server, or an entire environment of production web servers.
Remove-WindowsFeature Web-Server
Suddenly your web server isn’t a web server any more and you’re in big trouble*
Luckily, in keeping with the idea that users of systems need to be empowered with oversight, Octopus logs everything, including the script body, for easy review and blame sessions after someone has taken out your entire infrastructure.
OK, I kid. Yes, it’s possible to kill a fleet this way, but it’s also possible to hose your entire fleet with the other, less scary-looking features of OctopusDeploy – and that’s why there’s access control built-in in order to manage your risk and appropriately silo people and processes. If you don’t have access to a given role or environment, you can’t run scripts against it through the console – which is excellent.
So a toast to my new favourite thing. OctopusDeploy Script Console. Huzzah!
* of course, if you’ve designed your infrastructure correctly, you’ll have a way to self-heal from a snafu like this. Auto-scaling groups and health check to the rescue
