Using Octopus runbooks to schedule availability tasks

We are looking at significantly upgrading the way we use runbooks. We would setup triggered runs in production to ping our production services to confirm they are running.

What do you think? is this a reasonable thing to use Octopus for. I really like the Octopus interface for this. But I’m concerned it’s changing what we use Octopus for. It would become not just a system for managing deployments but now a system for running scheduled availability tasks in production.

Is this a reasonable thing to use Octopus for? Any tips on how to approach this? Currently we do everything on prem, via the single server and tentacles. I’m concerned our Octopus could get clogged up running all these scheduled triggers.

Hi @andrew_w,

Thank you for your questions surrounding the use of Runbooks.

I think it is great that you are starting to expand the scope for how you want to use your Octopus instance beyond your deployments.

Runbooks have been added for a reason, to help and support the lifecycle of your applications outside your deployments. As you may be aware, deploying code is not the only considerations for your applications, there can be operational support needed as well. This is why Octopus added Runbooks to help with those tasks.

Typically, Runbooks automate routine maintenance and emergency operations tasks, such as infrastructure provisioning, database management, and website failover and restoration. But it is not limited to just that.

Coming from the Ops side from previous DevOps roles, I love Runbooks within Octopus, it was a game changer moving from Windows Scheduled tasks, with better visibility using Octopus.

Disclaimer, Octopus is not a monitoring tool for your applications, there are tools dedicated for this.

However, if you are to continue with your idea, I would probably explore the following:

Firstly, I would take into consideration the “Task Cap” within Octopus and how this may be affected if you are to heavily use Runbooks. For simplicity, each Runbook that is run would count a 1 task. Given that you are on prem, you can increase the Octopus task cap yourself. Have a look at this page that also touches on some guidelines for configuring task caps.

I am not quite sure if you are sing Octopus High Availability but this can also help to scale out if needed. While I appreciate it is not always possible, I would explore the possibility to set up HA. With this you could have nodes that just run tasks in the example diagram here.

If you are using Runbooks to ping your applications, keep in mind the frequency you are doing this. For example if you are doing this every 1 min, for 5 applications (Runbook each). Every 1 minute you would use 5 tasks each minute so you may start to get queues waiting for each task to finish (you could look to use 1 Runbook to ping 5 applications then this would only be 1 task in your queue). Keep in mind the frequency of scheduled triggers, a lot of 1 minute tasks would start to queue quite quickly versus tasks that may be run every hour (staggered).

With a task such as ping (lets assume it is a simple HTTP check), you could look to run these using workers (providing they have appropriate access) to offload the overhead from your Tentacles.

I hope this helps to get you where you need to be, but if you are still unsure or have any further questions surrounding this, please do feel free to reach out.

All the best,

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.