Ansible happiness

Over the years I’ve had to manage an increasing number of servers, and recently I was tasked with an entire organisation’s servers of which I knew nothing about. The institutional knowledge had been lost - but the clock needs to keep ticking over.

After making sure everything was good and nothing would fall over, I decided to do some research into the best tool for the job. I came across Ansible, invested some time learning it, and have never looked back.

Why Ansible

There are a couple of configuration management / servers-as-code tools out there. One of the biggest reasons I like Ansible is that it is agentless. Nothing needs to live on any servers for it to do its thing. Generally, the less moving parts the better.

What agents have that Ansible doesn’t is continuous checking by default. Normally things like Salt will report back at intervals. This is easy enough to mimic with Ansible through cron, Ansible Tower or another CI/CD tool.

Example

A few examples go a long way. I use Ansible for any task involving provisioning of servers, deployment of software, or even updating this blog.

For securing of servers, I followed guides like My First Five Minutes On A Server as well as Linode’s guide and codified the important bits. The below is an excerpt from the securing script for an Ubuntu server:

---

- hosts: all
  become: yes
  gather_facts: no
  # We do these pre tasks to make sure Ansible runs nicely on the server
  pre_tasks:
    - name: 'install python2'
      raw: sudo apt-get -y install python-simplejson

  vars:
    UBUNTU_COMMON_DEPLOY_PASSWORD: "XXX"
    ubuntu_common_deploy_user_name: devops
    ubuntu_common_ssh_port: 22

  tasks:

  - name: Add deploy user
    user:
      name: "{{ ubuntu_common_deploy_user_name }}"
      password: "{{ UBUNTU_COMMON_DEPLOY_PASSWORD }}"
      shell: /bin/bash

  - name: Add authorized keys for deploy user
    authorized_key:
      user: "{{ ubuntu_common_deploy_user_name }}"
      key: "{{ lookup('file', '~/.ssh/ssh_id_rsa.pub') }}"

  - name: Add deploy user to sudoers
    lineinfile:
      dest: /etc/sudoers
      regexp: "{{ ubuntu_common_deploy_user_name }} ALL"
      line: "{{ ubuntu_common_deploy_user_name }} ALL=(ALL) NOPASSWD: ALL"
      state: present

  - name: Install aptitude
    apt: name=aptitude state=present update_cache=yes

  - name: Update APT package cache
    apt: update_cache=yes cache_valid_time=3600

  - name: Upgrade APT to the latest packages
    apt: upgrade=safe
    
  - name: Disallow password authentication
    lineinfile:
      dest: /etc/ssh/sshd_config
      regexp: "^PasswordAuthentication"
      line: "PasswordAuthentication no"
      state: present
    notify: restart ssh

  - name: Disallow root SSH access
    lineinfile:
      dest: /etc/ssh/sshd_config
      regexp: "^PermitRootLogin"
      line: "PermitRootLogin no"
      state: present
    notify: restart ssh

  - name: Allow SSH on fw
    ufw:
      rule: allow
      port: "{{ item }}"
      proto: tcp
    with_items:
    - "{{ ubuntu_common_ssh_port }}"
    notify:
    - restart ufw

  handlers:
  - name: restart ssh
    service: name=ssh state=restarted

  - name: restart ufw
    ufw: state=restarted

This does most of what you would look for:

• Adds a user
• Adds keys for that user
• Disables password login
• Adds user to sudoers
• Upgrades apt packages
• Turns off password auth and disallows root access
• Turns on the firewall and lets only SSH through

Handlers issue commands on completion of the task, so when you change ssh config, sshd gets restarted. Neat.

To use this playbook is just as easy:

ansible-playbook -i your.hosts playbook.yaml

This will run the playbook against all your servers as defined in your.hosts. Example:

[apps]
192.168.10.1
192.168.10.2

You can group servers and have group specific variables, roles and more. That goes a little deeper than this short blog post though.

//

Hopefully from the above you can see it’s all pretty straightforward. Things can get hairy (as they always can with software) but I’m using one playbook Ansible for a whole host of tasks across projects. For the bigger projects, the structure is more complex with roles, group variables, and many playbooks. Ansible can scale to what you need.

Ansible playbooks are (should be) idempotent - you run it N times and always the same result happens. If you have a clean server or a server already prepped/deployed to, running Ansible playbooks will not change the server at all. Deploying any number of app servers, for example, is now a matter of adding those servers to a hosts file and letting Ansible do its magic. At the end of the run, all servers will look and act the same. The dream. This can even be automated, letting servers automatically scale, added to a load balancer, and more when load gets too high.

I’d highly recommend reading Ansible for DevOps - it’s been the most valuable investment into my software engineering education in the recent past.