Literate DevOps (2014) | Hacker News Reader

Literate DevOps (2014)

howardism.org

42 pointsivanvas22 comments

Also check out https://github.com/khalidx/runbook (shameless plug). Executable markdown documents that you can run. Great for DevOps and sharing commands with the team.

This could be very cool combined with something like Pulumi!

Yes, that's exactly how I use it! Especially when I need to combine Terraform and CDK, or Terraform and Pulumi (depending on where I'm using which). The library has a nice CLI UI which makes running different things and gluing them together easy.

If you do end up trying this: try running "runbook ls" and "runbook run" after you download. It gives you an autocomplete UI that searches-as-you-type across all commands in your markdown document.

DevOps used to be elite. Few years of deveoper experience + cloud/containers knowledge to make all things run smoothly.

Nowadays DevOps is also fresh graduate who compiles embedded code for internet-disconnected 16 bit system.

I wish industry would standarise roles and responsibilities for the sake of job seekers and employers alike.

Standardized roles don't exist in any industry anywhere, and from both sides to be incentive is there to fudge responsibilities. From a business perspective, advertising for current trends makes talented applicants more likely to apply. On the flip side, an applicant likely wants to have a DevOps title even if they are simply doing clickops, as it makes them more appealing later down the line with 4+years experience in the title. "Title inflation" happens in all industries - you see it with people being called senior engineers with 2-3 years of experience, for example.

Gitlab has a way built in to make Jupyter notebooks into "Runbooks."

https://docs.gitlab.com/ee/user/project/clusters/runbooks/

Isn't this just Ops?

Devops just means ops, but the sysadmin is required to not be a complete dumbass who can't even write simple scripts.

It just applies basic common sense to ops. "Basic common sense" is commonly called "software engineering best practices."

Best "practical" description of DevOps that I've read so far.

Simply because DevOps is the onomatopoeic sound devs made when slipping on their banana peel (crappy code pushed in production) with a loud "ops" who happen to be both a sad face and a cry for help...

Beside that while this was the video that pushed me from Unix to Emacs (yes, correctly because that's was my switch not Vim in general but Unix model to Emacs/classic Desktop model) I never manage anything this way, instead most of my setups are tangled configs from org-mode, something I can't avoid to avoid entering in crazy kill mode looking to some YAML-lovers devs fresh blood... In many devops modern @$£&%"£CENSORED!!£!.

Or you can just use markdown with source blocks.

IntelliJ will let you execute blocks in markdown files.

You can also use stuff like this: https://github.com/earldouglas/codedown to programmatically extract code from a markdown file.

The results are stored inline, and the data can be re-used in different blocks even between languages. It doesn't look like codedown does that, can markdown do that with source blocks ?

No but storing the output of a command is trivial.

to be used in doc ?

Back in 2014 when this was first published I found it really inspiring and incorporated many of the techniques it describes into my daily workflow. It's been a while, so I wonder what he's doing now.

If you want Markdown instead of Org Mode, Codebraid is great.

https://github.com/gpoore/codebraid

This was before Infrastructure-as-Code, Immutable Infrastructure, etc were popularized. 99% of the time, on greenfield systems, you shouldn't have to use Puppet or Chef or Ansible.

Runbooks-as-Code is also a great practice, similar to the notebook shown here. But they should be limited to one-time actions, like triage, recovery, etc.

Can you point to a repo that shows how this is done, are you saying docker-compose or nix or something? source: not a devop, just a vintage dev.

note that docker-compose is lately "docker compose" -- i.e. a plugin to mainstream docker-ce

> 99% of the time, on greenfield systems, you shouldn't have to use Puppet or Chef or Ansible.

I'm not entirely sure about this. One one hand, being able to set everything up once manually and just documenting the process usually will be easier, so people will opt for this, if given the choice.

Then again, I'm pretty sure that certain people aren't all that good at documentation and will write as little of it as possible, leading to this greenfield project that will inevitably turn into a brownfield project 5 years down the line now being at a disadvantage.

By then, nobody will really have any idea how to set up a new environment, or what exactly it needs. Worse yet, if you have some sloppily written documentation, that actually is no longer accurate and lies to you.

I'm pretty sure what he meant was that Puppet/Chef is for wrangling VMs, and for a greenfield project, there are better tools available than VMs.

If not, I agree with you, if you need them, you should use Chef/Puppet every time.

> I'm pretty sure what he meant was that Puppet/Chef is for wrangling VMs, and for a greenfield project, there are better tools available than VMs.

That's also fair, as long as you don't have requirements to run on-prem, where a lot of the cloud offerings won't usually be available.

Reply on news.ycombinator.com