Maintaining servers falls into two phases: First, bang head until server works; second, capture effort into some automation tool like Puppet or Chef. Recently, I’ve been playing around with making the first phase closer to the second. For lack of a better word, I’m calling it literate devops.
I’ve talked about using org-mode’s literate programming model to investigate new ideas and crystallize thoughts, and this approach appears to work well for me, since I lack those esoteric sysadmin skills.
Tell us a Story
Once upon a time, I was tasked with patching an RPM. Clearly, not in my comfort zone, so my initial plan of attack was:
- Use Vagrant to create a disposable CentOS system
- SSH into this virtual machine and to download and run commands
- Rinse and repeat step #2 until successful
First step is pretty easy and well documented elsewhere, but TIL
that you can use
ssh directly to your Vagrant-based virtual
machine with this little magic:
vagrant ssh-config client >> $HOME/.ssh/config
Which appends some lovely host-connection magic. Goody.
Now comes the literate devops. Since I always have Emacs hosting
with my current sprint’s notes, so instead of opening up a terminal
to the virtual machine, I instead created a new header in my
org-mode file, and started entering the commands in the file.
What good is this? Well, it allows me to log, document and execute each command.
For instance, here is a screen-shot of a section of my Emacs buffer:
Clicking the hyperlink gives me the online details I discovered, and I can enter prose about each command, and I can execute the commands from within Emacs.
Yes. I can execute the commands from within Emacs.
C-c C-c (Control-C twice) runs the code based on the
language, and in this case, it runs it within my shell. The results
are placed back into the buffer or written to a file, and more.
What about the Virtual Machine?
sh bit tells Emacs to run it on my local system’s
shell, but in this case, I want it to run it on my virtual machine
(or even on my development server in my lab). I just run this little
bit of Emacs that include at the top of the file:
The first code block is some Emacs Lisp code that changes the
default command for executing
sh code, and the second block I run
to see if it connects correctly.
Now, I can continue learning how to accomplish my target, all the while documenting and validating my steps. The end result can be exported to web or wiki page.
What about Verbose Commands?
Yes, some executing some commands can be quite time-consuming and verbose, but often I need to search the results, and having the results in an Emacs buffer allows me better searching.
Often I use a “drawer” (which is just a way to identify the beginning and end of the output:
Which allows me to place the cursor of this drawer and hit the
key to hide or show the output:
Can you Use the Output?
The results of some commands are often needed for the next command, and I’m sure you love using your mouse to copy and paste part of the output that you want to use.
For instance, I needed a list of an RPM’s dependencies:
Notice that I named this source block. Also notice how Emacs automatically broke the results up into a table. By default, the output from shell commands are split along newlines and spaces…which is quite useful for me.
For here is another source block that creates a variable named
DEPENDS that uses rows 2 through 10 of the first column as an
array. I can then download the RPMs I want without any mouse
No, this shouldn’t replace real DevOps automation, but this seems like a good way to take notes before you sit down to write that cookbook.