Runbook – DevOps, automated | Hacker News Reader

Runbook – DevOps, automated

runbook.io

77 pointsspking26 comments

Why would anyone want this in the cloud? Self hosted, absolutely. I wouldn't want any service to store credentials that can remotely bounce my VMs or login and restart services.

edit: If I wanted to run my own instance what things are missing? That doesn't seem very clear.

Also if you wanted to stand up your own instance you could follow this.

http://runbook.readthedocs.org/en/master/developers/install/

It's geared more towards a development environment for the reasons I mentioned above but it would get you a running instance for sure.

Thats a good point, right now we work solely off of API's and don't offer any way for us to store usersnames/passwords. The thought is that API credentials can be revoked easier. In general we are looking to meet the market of folks who are 100% in cloud environments, where the adoption of a SaaS solution is not as much of a concern. But in the future there are some ideas on how to handle self hosting and not sending credentials to the SaaS environment.

But we are open source, and our license does allow for self hosting: https://github.com/asm-products/cloudroutes-service/blob/mas...

> In general we are looking to meet the market of folks who are 100% in cloud environments, where the adoption of a SaaS solution is not as much of a concern

In theory you could meet this need via a prebuilt AWS image or something. Then people can still get up and running with one click but within their own cloud environments.

True, that is something worth looking into. We are also of course looking at setting up some Docker images for quick and speedy deployments.

Few more options for "IFTTT for DevOps": http://docs.factor.io/ http://stackstorm.com/ http://www.airstack.io/ https://www.cloudmunch.com/

All interesting projects with their own twist on it. The space we are aiming to hit can be equated to IFTTT + Nagios.

I can't speak for others, but I can for Factor.io’s twist... (1) It is Open Source + Hosted + Pro. (2) The recipes ("workflows") can include multiple steps, sequential, and parallel activities; not just limited to if-this-then-that. (3) Workflows are defined programmatically using a Ruby-DSL. (4) You can create both actions and listeners (like events/monitors), though some of the others support this too. (5) It's been around for 2+ years, built with feedback from 100+ dev teams, and used by 1000s.

Another similar tool is http://www.rundeck.org this one is open source and self-hosted.

Runbook is also opensourced https://assembly.com/runbook/repositories (I guess all products on assembly are)

I was worried there for a second when the page mentioned Runbook was built on Assembly, at least until I realized that Assembly was some website rather than the programming language we all know and love.

Looks interesting, whatever the case.

I think your pricing is honestly too low. First, nobody here is complaining that your pricing is too high. Second, when evaluating pricing, it's useful to ask "what serious customer would pay $5/mo but not $15 or $25 if we are providing real value to them?"

I run Cronitor.io, a monitoring service for scheduled jobs. In our case, we have about as many users on our mid-priced plan as we do on our entry level plan. The message our subscribers send us is: we're not shopping on price, your fees are reasonable, just keep building your product.

Interesting project! Can you tell a bit more about cronitor.io? Is this a side project or a full time project? How many users are using your service? 100, 1000, 10000 ?

Looks interesting - how does this compare to something like Monit?

At the moment we are taking a very IFTTT style approach where we have monitors that are external facing that can test things like TCP ports, HTTP status codes and anything we can get at with a webhook or API (i.e. Datadog, Papertrail, Heroku). When we resolve things it is all via external services that we can integrate with via API's or webhooks (Commando, DigitalOcean, Rackspace, AWS and so on).

On our roadmap is building an agent (and there is a wrapper for our webhooks), this would allow us to run monitors and reactions locally on the server itself. Where we would shine over a tool like Monit is that once we have an agent you could define that reaction to happen on any server.

So for example if we detected a database error using a keyword search on the web app. You would be able to execute commands to fix it on whatever servers you define.

So think of it like, being able to run the actions across as many servers as you want.

Congrats @madflojo! We're integrating with Runbook with two of our apps right now.

I'm super excited to see Runbook launch. It has been exciting to watch @madflojo collaborate with the rest of the Assembly community towards this launch.

Since Runbook is a product built on Assembly, anyone can help out. If you have any suggestions or feedback the conversations and future roadmap are here: https://assembly.com/runbook

Higher level product concept aside, here is some minor visual feedback.

I think one or more images overflow the main content container, causing the site to look broken on my iPhone 6 plus. I don't know how much cross platform testing your done, but it's a data point. I wasn't too excited to read the marketing copy as a result.

I don't love your logo. It's a book on a cloud with some kind of diagonal line for some reason.

That is some good feedback, we have a bounty open to revise the "responsiveness" of our site. To make it work a bit better cross platform. We move pretty fast I doubt it would take us very long to have that fixed up.

Kind of didn't work. I signed up, and i was trying to set something up on my staging to scale it out if a dyno was idle, but it didn't appear to work. I had it at zero dynos, so you'd expect it to scale up immediately.

Also, not great UI design. I kept wanting to manage my monitors, but to do so, I had to hit Status, and then hit Manage Monitors. I'd rather have had it on the sidebar, like Add Monitor was.

Hey jprince, I'd have to look at the "Not Idle" monitors for dynos that don't exist. The way that monitor works is it looks at the monitor status to see if any are idle, if there are no dynos then there would be none idle.

The UI is also something that we are working on, in fact it is our next big project. We are a growing app so some things aren't exactly perfect but were working towards it.

Ok, I had a feeling this was an edge case.

It says its open source at the bottom of the page, but no link to a repo.

EDIT: My apologies, I should've looked around more first before posting.

Hi, We are an assembly product so there is a link to our Assembly page: https://assembly.com/runbook which is where we lead the development and you can find a link to our repo. Also: https://github.com/asm-products/cloudroutes-service we just changed our name from CloudRoutes to Runbook so forgive any old references.

Here are the repos:

https://github.com/asm-products/cloudroutes-service

https://github.com/asm-products/cloudroutes-developerdocs

Kudos for successfully launching such an ambitious project, I've been following the project on Assembly.

That CTA button is pretty epic, though.

Reply on news.ycombinator.com