In Part I, I talked about why Ansible and how to configure your own installation using Vagrant, VirtualBox, and Ansible. Now, let’s take a closer look at using Ansible along with the details of my demo playbook collection ansible-mojo.
Once Ansible is up and running, it is extremely useful for managing nodes using ad-hoc commands. However, it really shines once you start developing collections of commands, or “plays”, in the form of “playbooks” to manage nodes. Similar to recipes and cookbooks in Chef, Ansible’s plays and playbooks are the basis for a best-practice implementation of Ansible to manage your infrastructure in a consistent, flexible, and repeatable fashion.
For ansible-mojo, I wanted to create a set of simple playbooks that would be helpful in demonstrating how to configure nodes with some basic things like:
- a dedicated user account “ansible” for deployment standardization,
- installation of standard packages,
- management of users and sudoers content
Initial Ansible Playbook Run
The anisible-mojo repo contains several files: playbooks, a variables file, and a couple of shell environment files. All playbook content is based on YAML-formatted text files that are easily understandable. I opted to have a single primary playbook (main.yml) that does some initial node configuration then includes other playbooks for specific configuration changes like configuring users (user-config.yml) and installing sysstat for SAR reporting (sysstat-config.yml).
Before I go into details on each of the playbooks, let’s go ahead and do an initial playbook run against our Ubuntu Vagrant box so that we can issue further commands using our dedicated deployment user account “ansible” instead of the “vagrant” user.
NOTE: Be sure that you change authorized_keys in ansible-mojo to contain the public key that you configured your ssh-agent to use for deployment as mentioned in Part I.
In this case, I am using a Vagrant machine called “myvm” and will specify the -e override for ansible_ssh_user to ignore the remote_user setting in ansible.cfg:
[rcrelia@fuji ansible]$ ansible-playbook main.yml -e ansible_ssh_user=vagrant
PLAY [all] *********************************************************************
TASK [setup] *******************************************************************
ok: [myvm]
TASK [Ensure ntpdate is installed] *********************************************
changed: [myvm]
TASK [Ensure ntp is installed] *************************************************
changed: [myvm]
TASK [Ensure ntp is running and enabled at boot] *******************************
ok: [myvm]
TASK [Ensure aptitude is installed] ********************************************
changed: [myvm]
TASK [Update apt package cache if older than one day] **************************
changed: [myvm]
TASK [Add user group] **********************************************************
changed: [myvm] => (item={u'user_uid': 2000, u'user_rc': u'bashrc', u'user_profile': u'bash_profile', u'sudoers': True, u'user_groups': u'users', u'user_gecos': u'ansible user', u'user_shell': u'/bin/bash', u'user_name': u'ansible'})
changed: [myvm] => (item={u'user_uid': 2001, u'user_rc': u'bashrc', u'user_profile': u'bash_profile', u'sudoers': False, u'user_groups': u'users', u'user_gecos': u'Bob Dobbs', u'user_shell': u'/bin/bash', u'user_name': u'bdobbs'})
... SNIP ...
TASK [Install sysstat] *********************************************************
changed: [myvm]
TASK [Configure sysstat] *******************************************************
changed: [myvm]
TASK [Restart sysstat] *********************************************************
changed: [myvm]
PLAY RECAP *********************************************************************
myvm : ok=17 changed=15 unreachable=0 failed=0
Success! Now, we should have the “ansible” user account provisioned on the Vagrant machine and we will perform all future Ansible plays using that account as specified in ansible.cfg in the remote_user setting.
A Closer Look at Playbooks
ansible-mojo contains several files, with all Ansible syntax included in the YAML files:
- main.yml
- vars.yml
- reboot.yml
- Playbooks nested below main.yml:
- user-config.yml
- ssh-config.yml
- sudoers-config.yml
- sysstat-config.yml
- user-config.yml
Each of these files with the exception of vars.yml is an Ansible playbook. I created a primary playbook called “main” which in turn references a file containing miscellaneous variables (another YAML file called vars.yml), along with two other playbooks, user-config (configures user accounts) and sysstat-config (configures SAR reporting). These latter two files are nested playbooks: their execution is dependent on syntax in the main playbook and the vars_file. Finally, user-config includes two playbooks, one for configuring SSH in user accounts and one for configuring sudo access.
At the beginning of the main playbook, we see that the plays are scoped to all hosts in Ansible’s inventory (hosts: all), that plays will be run as a privileged user on the nodes (become: yes), and that some variables have been stored outside of playbooks in a single location called vars.yml. This pattern of using vars_files allows you to have a single place for information that you may not want to distribute along with playbooks (e.g., user account details) for security reasons.
Next, Ansible tasks (or actions) are defined for installing and configuring ntpd on our nodes, along with aptitude, and a command to update the apt packages on a node if the last update was longer ago than 24 hours.
The nesting of playbooks is a pattern that supports reusability and portability of playbook content, provided you don’t hardcode variables in them. Let’s take a closer look at some of these nested playbooks.
Managing users: user-config.yml
Since user-config is a nested playbook, it consists of a sequence of tasks without any operating parameters like host-scoping or privilege/role settings. It does five things before calling its own nested playbooks at the end:
- Creates a user’s primary group using the user’s UID as the GID, via the Ansible group module
- Creates a user via the Ansible user module
- Creates a user’s .bash_profile via the Ansible copy module
- Creates a user’s .bashrc via the Ansible copy module
- Creates a user’s $HOME/bin directory via the Ansible file module
The syntax is pretty clear about what is happening if you have even the most basic sort of experience managing user accounts on a UNIX/Linux server. Isn’t Ansible awesome?
What may not be so clear is the syntax that uses the “item.” prefix in variable names. Basically, I designed the playbook to use with_items feature of Ansible so I could iterate through multiple users without duplicating a lot of syntax. The “{{ users }}” variable is a referencing a YAML list called users that is stored in the variables file vars.yml. Looking at that list, it becomes apparent that we are cycling through attributes of each user without hardcoding any user-specific variables in our playbook:
users list from vars.yml:
users: - user_name: ansible user_gecos: 'ansible user' user_groups: "users" user_uid: 2000 user_shell: "/bin/bash" user_profile: bash_profile user_rc: bashrc sudoers: yes - user_name: bdobbs user_gecos: 'Bob Dobbs' user_groups: "users" user_uid: 2001 user_shell: "/bin/bash" user_profile: bash_profile user_rc: bashrc sudoers: no
When you write playbooks in Ansible, you should design your plays as generically as possible so that you can re-use your playbooks across different projects and nodes.
Next, user-config includes the ssh-config playbook which has two tasks: Setup a user’s .ssh directory and the user’s authorized_keys content. In this case, each user is being configured to use the same authorized_keys data, which is probably not how you would configure things in an actual deployment from a security best-practices perspective.
Lastly, user-config includes the sudoers-config playbook which uses Ansible’s lineinfile module to specify sudoers syntax to allow for passwordless sudo invocation. We need this for our ansible account, which will be performing Ansible operations for us non-interactively. This play is special in that it is constrained to only be run when the user is supposed to be added to sudoers (via use of Ansible’s when clause). How is this controlled? Through the sudoers attribute from the users list in vars.html:
users:
- user_name: ansible
user_gecos: 'ansible user'
user_groups: "users"
user_uid: 2000
user_shell: "/bin/bash"
user_profile: bash_profile
user_rc: bashrc
sudoers: yes
Managing packages: sysstat-config.yml
One of the classic UNIX/Linux performance monitoring tools is sar/sadc. In the open-source world, sar is packaged within the sysstat tool. One of the first things I do on a new machine is to make sure sar is installed, configured, and operational. So, I created a playbook that installs and configures the sysstat package.
One neat tool in Ansible is the lineinfile module which is useful to make sure a specific line is included in a text file, or some pattern within a line is replaced via a back-referenced regular expression. In the case of sysstat, there is a config file on Ubuntu, /etc/default/sysstat, that ships with a default “off” configuration (i.e., ENABLED=”false”). I used the lineinfile module in sysstat-config.yml to change that line and activate sysstat:
--- # Install sysstat for sar reporting - name: Install sysstat apt: name: sysstat state: present - name: Configure sysstat lineinfile: dest: /etc/default/sysstat regexp: '^ENABLED=' line: 'ENABLED="true"' state: present - name: Start sysstat service: name: sysstat state: started enabled: yes
After the sysstat package is installed (task #1), and its configuration file modified (task #2), I tell Ansible to make sure sysstat is started and enabled to start on reboot via the service module (task #3).
BONUS Play: Interactive Ansible and Server Reboots
Everything you do with Ansible is typically designed to be non-interactive. However, there may be some things that it makes sense to have some sort of interactive processing for depending on your workflow. I thought it might be interesting if I could trigger a server reboot and pause an Ansible playbook until the server(s) all came back online. This is the purpose of the reboot.yml playbook. This playbook could be used after updating kernel packages on hosts, for example. It would need to be modified to add control logic if rebooting all hosts simultaneously in Ansible’s inventory is undesirable. If you want to constrain the run of this all-hosts scoped playbook to a single host in your inventory, you can use the –limit filter:
ansible-playbook --limit myvm reboot.yml
Summary
This wraps up my overview of ansible-mojo’s playbook content and organization. Hopefully by now, you recognize the power and value of Ansible and appreciate just how easy it is to use. In Part I, you learned how to arrange and use Vagrant, VirtualBox, and a source-based copy of Ansible to create a lab environment for your Ansible testing.
In Part II, you learned how to create and use a sequence of Ansible plays to achieve some very common systems deployment goals: creating a deployment user, managing users, distributing ssh authorizations, configuring sudo, and installing packages.
You’ve also learned how to nest playbooks and why you may want to consider stashing certain variables and configuration lists in a file separate from your playbooks.
By downloading ansible-mojo, you can start using Ansible on your own machine immediately, which was my goal for releasing it. I hope you find Ansible as much of a joy to work with as I do.
Future changes to ansible-mojo and accompanying blog posts may or may not include:
- creating more distro-agnostic playbooks (e.g., plays that work for both CentOS and Ubuntu)
- integration with Vagrant for local provisioning
- development of Ansible roles for publishing to Galaxy
Until then, happy hacking and may Ansible make your world better! Cheers!!
randops.org 