Live data from Hacker News

Runme – Interactive Runbooks Built with Markdown

runme.dev

21–30 of 47 posts

Re: Runme – Interactive Runbooks Built with Markdown

#21

For those who don't know, Jupyter has a bash kernel: https://github.com/takluyver/bash_kernel And you can run Jupyter notebooks from the CLI with Ploomber: https://github.com/ploomber/ploomber

Very cool, thanks for calling that out, we are big fans of Jupyter!

Re: Runme – Interactive Runbooks Built with Markdown

#22
post #11

Earlier quoted context omitted.

There are actually many differences. We focus more on operational tasks, and allow cells to contain code from a number of programming languages in addition to python. In fact most folks are using Runme to make executing runbooks full of bash commands a better experience.

Ok, so from the front page I got the impression it was only bash. I'm hitting cloud APIs via python so Jupyter works for that, and I'm using the python to ssh into systems and run bash there. The two missing things from Jupyter are 1. ssh-ing to remote hosts and running shell scripts (we do it with a bunch of code) and 2. running cells concurrently. But python is a hard requirement.

VS Code can attach to VMs via SSH and the notebooks will transparently run on the remote host. Python works out of the box as mentioned. I’m a co-creator of Runme btw.

Re: Runme – Interactive Runbooks Built with Markdown

#26

My company is investing heavily in interactive runbooks (their own impl) and while I kinda dislike the idea of runbooks in general this is a nice implementation. Interactive Runbooks exist in some sort of tech-debt limbo where you have enough time to write a nice little runbook but apparently not enough time to properly automate whatever the task is. Ideally automation is easy and all change flows through a SDLC and…

Wouldn't Ansible be the better runbook then?

Re: Runme – Interactive Runbooks Built with Markdown

#27

My company is investing heavily in interactive runbooks (their own impl) and while I kinda dislike the idea of runbooks in general this is a nice implementation. Interactive Runbooks exist in some sort of tech-debt limbo where you have enough time to write a nice little runbook but apparently not enough time to properly automate whatever the task is. Ideally automation is easy and all change flows through a SDLC and…

> Interactive Runbooks exist in some sort of tech-debt limbo where you have enough time to write a nice little runbook but apparently not enough time to properly automate whatever the task is

I think this is a really common place to fall into. Automating 100% of conditions is hard, but having a google-doc full of bash commands is kinda meh.

One of my previous teams decided on a "Maintainer Lambda" which would help with some tasks we couldn't automate fully. The Lambda could either make an action (trigger a db backup, trigger a bounce, etc) or it could perform some query (find FQDN hostname of server where ${INPUT} metric is in alarm). It'd help with calling complex APIs (eg. AWS APIs) repeatably, and testable, and it'd handle any permissions and input validations. The Lambda had unit testing, and it could run automatically under certain limited conditions. Over time, we've added to it, and let it handle more tasks, as long as it'd log it's actions in a ticket (eg. drain server, then auto-bounce on mem-full alarm).

We'd embed cURL scripts into the runback doc, to trigger the functions manually. But the biggest win was whenever we got an automated ticket, for things like alarming metrics, it'd auto-run and parse the ticket, spitting out useful commands into the comments that the on-call could run (eg. copy+paste'able SSH-to-host commands based on which server triggered alarm). It's basically a reverse-run book. Instead of looking up what to do, we let the ticket tell us what to do, then slowly automate those steps.

Re: Runme – Interactive Runbooks Built with Markdown

#28

My company is investing heavily in interactive runbooks (their own impl) and while I kinda dislike the idea of runbooks in general this is a nice implementation. Interactive Runbooks exist in some sort of tech-debt limbo where you have enough time to write a nice little runbook but apparently not enough time to properly automate whatever the task is. Ideally automation is easy and all change flows through a SDLC and…

I have a bunch of things I want to use them for. amongst them

* tutorials and other show and tell type stuff.

* troubleshooting: have a collaboratively-authored runbook that queries APIs, loads/aggregates data in some way and allows people to interactively examine response data (like a debug terminal sort of thing but with graphing etc)

I think they're really exciting.

Re: Runme – Interactive Runbooks Built with Markdown

#30
While in principle I agree with the usefulness of this approach I wonder about how actually it benefits orgs and projects.

Seems to me that the fact that there exist extensive runbooks that are maintained separately from the scripts of the project that either duplicate actions between them or those just only exist in runbooks are massive smells.

Post reply on HN