Ansible, Part III: Playbooks

Shawn Powers — Mon, 19 Feb 2018 16:50:14 +0000

Playbooks make Ansible even more powerful than before.

To be quite honest, if Ansible had nothing but its ad-hoc mode, it still would be a powerful and useful tool for automating large numbers of computers. In fact, if it weren't for a few features, I might consider sticking with ad-hoc mode and adding a bunch of those ad-hoc commands to a Bash script and be done with learning. Those few additional features, however, make the continued effort well worth it.

Tame the Beast with YAML

Ansible goes out of its way to use an easy-to-read configuration file for making "playbooks", which are files full of separate Ansible "tasks". A task is basically an ad-hoc command written out in a configuration file that makes it more organized and easy to expand. The configuration files use YAML, which stands for "Yet Another Markup Language". It's an easy-to-read markup language, but it does rely on whitespace, which isn't terribly common with most config files. A simple playbook looks something like this:


---

- hosts: webservers
  become: yes
  tasks:
    - name: this installs a package
      apt: name=apache2 update_cache=yes state=latest

    - name: this restarts the apache service
      service: name=apache2 enabled=yes state=restarted

The contents should be fairly easy to identify. It's basically two ad-hoc commands broken up into a YAML configuration file. There are a few important things to notice. First, every filename ends with .yaml, and every YAML file must begin with three hyphen characters. Also, as mentioned above, whitespace matters. Finally, when a hyphen should precede a section and when it should just be spaced appropriately often is confusing. Basically every new section needs to start with a - symbol, but it's often hard to tell what should be its own section. Nevertheless, it starts to feel natural as you create more and more playbooks.

The above playbook would be executed by typing:


ansible-playbook filename.yaml

And that is the equivalent of these two commands:


ansible webservers -b -m apt -a "name=apache2
 ↪update_cache=yes state=latest"
ansible webservers -b -m service -a "name=apache2
 ↪enabled=yes state=restarted"

Handling Your Handlers

But a bit of organization is really only the beginning of why playbooks are so powerful. First off, there's the idea of "Handlers", which are tasks that are executed only when "notified" that a task has made a change. How does that work exactly? Let's rewrite the above YAML file to make the second task a handler:

Go to Full Article

Getting Help From Linux - Part 2 Info

Jayson Broughton — Tue, 11 Oct 2011 14:45:23 +0000

by Jayson Broughton

Well here we are again, at part two of the 'Getting Help from Linux' series. In this blog post I'll be talking about using Info to get help from Linux. In my previous post I spoke about how Info came about, but just in case you missed it I'll give you another quick lesson. Gnu Info was created by the Free Software Foundation and in my experience is used by all of Gnu's software for their version of 'man' pages. Info may contain much more information than what you can find in Man pages, and sometimes contains much more than you ever really need. The good thing about Info is that it is a hypertext markup utility. This makes it much easier to navigate through via hyperlinks embedded in emacs, than simply using arrow keys to navigate through information. While Man uses the Less utility to control the display, the info utility itself is designed to display Info pages. For those of you familiar with emacs, it appears the layout may be the same, along with some of the basic navigation. But that's where the two applications can differ. If you're using the Info application then your commands will be different than if you're viewing info files in Emacs. This article is about reading Info pages inside of info.

Layout and Navigation

Okay, I won't lie, navigation in emacs makes my head spin. For some people this may come naturally, for those of us that have lived on vi all their lives the old adage 'you can't teach an old dog new tricks' really hits home when it comes to figuring out all of the emacs tips and tricks. If anyone has actually gone through gnu.org's website on the Texinfo manual you know what I'm talking about. The document on how to use Texinfo is 36 pages long, quite a bit longer than navigating Man pages in Less. As far as layout goes, sections are broken down into what Info considers 'nodes', so if you see the reference to nodes in here then that's what I'm talking about. As stated earlier, the info documents are written in hypertext, which makes it easier to navigate through than Man pages. When you first execute 'info ' you are presented with the index for the subject that you are looking for. Now before you start hyperventilating, think of the Info layout as a Tree (Top Node) with various branches spanning from the tree (Individual Nodes). The Branches just point back to the main 'branch'.

Before I get ahead of myself, let me first explain the main window.

At the bottom of your window is what is called the Mode Line. The mode line just describes what you are viewing above, including information about the file, the node, number of lines, compression information, etc. Here are some examples and explanations of Mode Lines: