Ansible : rolling upgrades or updates.

Making a change to live servers in production is something which has to be done with extreme care and planning. Several deployment types such as blue/green, canary, rolling update are in use today to minimize user impact. Ansible can be used to orchestrate a zero-downtime rolling change to a service.

A typical upgrade of an application, such as patching, might go like this –

  1. disable monitoring alerts for a node
  2. disable or pull out from load balancer
  3. make changes to server
  4. Reboot node
  5. wait for node to be UP and do sanity check
  6. put node back to load balancer
  7. turn on monitoring of node

Rinse and repeat.

Ansible would be a great choice in orchestrating above steps. Let us start with an inventory of web servers, a load balancer and a monitoring node with nagios –




The web servers are running apache2, and we will patch apache and the kernel. For the patch to take effect, the servers need to be recycled. We will perform the patching one node at a time, wait for the node to be healthy and go to the next. The first portion of our playbook would be something like this –

- hosts: webservers
  serial: 1

  - name: Stop apache service
    service: name=httpd state=stopped

  - name: update apache
    yum: name=httpd state=latest
  - name: Update Kernel
    yum: name=kernel state=latest
  - name: Reboot server
    shell: /sbin/reboot -r +1

  - name: Wait for webserver to come up
    wait_for: host={{ inventory_hostname }} port=80 state=started delay=65 timeout=300

I haven’t included the playbook tasks for disabling/enabling monitoring as well as removing/adding node to the load balancer. The procedures might differ depending on what type of monitoring system or load balancer technology you are using. In addition to this, the sanity check show is a simple port 80 probing, in reality a much more sophisticated validation can be done.

References –

Ansible – How to run a portion of a playbook using tags.

If you have a large playbook it may become useful to be able to run a specific part of it or only a single task without running the whole playbook. Both plays and tasks support a “tags:” attribute for this reason.

In this specific scenario, I have a playbook which configures all productions servers from the moment the servers boot till they start taking traffic. While testing the plays in dev environment, I was debugging an issue on the parts which does dns configuration. This is where the “tags” attributes comes handy –

1. Tag the task –

- name: Configure resolv.conf
  template: src=resolv.conf.j2 dest=/etc/resolv.conf
  when: ansible_hostname != "ns1"
    - dnsconfig

2. Run only the tasks tagged with a specific name –

root@linubuvma:/etc/ansible# ansible-playbook -i dc1/hosts dc1/site.yml --tags "dnsconfig" --check

PLAY [Setup data center 1 servers] *****************************************************

TASK: [common | Configure resolv.conf] ****************************************
skipping: [ns1]
changed: [docker]
ok: [ns2]
ok: [whitehat]
ok: [mail]
ok: [www]
ok: [ftp]

PLAY RECAP ********************************************************************
whitehat                   : ok=1    changed=0    unreachable=0    failed=0
docker                     : ok=1    changed=1    unreachable=0    failed=0
ns1                        : ok=0    changed=0    unreachable=0    failed=0
ns2                        : ok=1    changed=0    unreachable=0    failed=0
mail                        : ok=1    changed=0    unreachable=0    failed=0
www                   : ok=1    changed=0    unreachable=0    failed=0
ftp                   : ok=1    changed=0    unreachable=0    failed=0

Ansible playbook will run only the task with the specified tag, it will skip the rest of the tasks in the playbook. Use the ‘–list-tags’ flag to view all the tags.

References –

Ansible – Enable logging

By default, Ansible logs the output of playbooks to the standard output only. In order to enable logging to a file for later review or auditing, it can be turned on by setting log_path to a path location where Ansible has a write access.

In my case, i have added the “log_path” setting in the ansible configuration file “/etc/ansible/ansible.cfg”

# grep log_path /etc/ansible/ansible.cfg
log_path = /var/log/ansible.log

Now I can view the log file to all the details on ansible runs –

root@linubuvma:/etc/ansible# ansible-playbook tasks/groupby.yml --check
PLAY [all:!swarm:!docker1] ****************************************************

TASK: [group_by key=os_{{ ansible_os_family }}] *******************************
changed: [ns2]

root@linubuvma:/etc/ansible# ls -al /var/log/ansible.log
-rw-r--r-- 1 root root 4255 May 16 21:21 /var/log/ansible.log
root@linubuvma:/etc/ansible# head  /var/log/ansible.log
2015-05-16 21:21:43,732 p=22946 u=root |
2015-05-16 21:21:43,732 p=22946 u=root |  /usr/local/bin/ansible-playbook tasks/groupby.yml --check
2015-05-16 21:21:43,732 p=22946 u=root |
2015-05-16 21:21:43,734 p=22946 u=root |  ERROR: the playbook: tasks/groupby.yml could not be found
2015-05-16 21:21:48,575 p=22954 u=root |
2015-05-16 21:21:48,576 p=22954 u=root |  /usr/local/bin/ansible-playbook tasks/groupby.yml --check
2015-05-16 21:21:48,576 p=22954 u=root |
2015-05-16 21:21:48,594 p=22954 u=root |  PLAY [all:!swarm:!docker1] ****************************************************
2015-05-16 21:21:48,609 p=22954 u=root |  TASK: [group_by key=os_{{ ansible_os_family }}] *******************************
2015-05-16 21:21:48,641 p=22954 u=root |  changed: [ns2]

It logs dry-runs (–check) as well and it is smart enough not to log Password arguments.

References –

How to run playbooks against a host running ssh on a port other than port 22.

Ansible is a simple automation or configuration management tool, which allows to execute a command/script on remote hosts in an adhoc or using playbooks. It is push based, and uses ssh to run the playbooks against remote hosts. The below steps are on how to run ansible playbooks on a host running ssh on port 2222.

One of the hosts managed by ansible is running in a non-default port. It is a docker container listening on port 2222. Actually ssh in container listens on port 22, but the host redirect port 2222 on host to port 22 on container.

1. Use environment variable –

 ansible-playbook tasks/app-deployment.yml --check -e ansible_ssh_port=2222

2. specify the port in the inventory or hosts file –

Under hosts file set the hostname to have the format ‘server:port’ –


Let us run the playbook now –

root@linubuvma:/tmp/ansible# cat tasks/app-deployment.yml
- hosts: docker-hosts
    app_version: 1.1.0
  - name: install git
    apt: name=git state=latest
  - name: Checkout the application from git
    git: repo= dest=/srv/www/myapp version={{ app_version }}
    register: app_checkout_result

root@linubuvma:/tmp/ansible# ansible-playbook tasks/app-deployment.yml

PLAY [docker-hosts] ************************************************************

TASK: [install git] ***********************************************************
changed: [docker1]

TASK: [Checkout the application from git] *************************************
changed: [docker1]

PLAY RECAP ********************************************************************
docker1                    : ok=2    changed=2    unreachable=0    failed=0

References –

Sooner or later, you will find yourself adding sensitive data into Ansible playbooks, host or group vars files.Such information might include MySQL DB credentials, AWS secret keys, API credentials etc. Including such sensitive information in plain text might not be acceptable for security compliance reasons or even lead to your systems being owned when your company hires a third party to do pen testing and worst yet by outside hackers. In addition to this, sharing such playbooks to public repositories such as github won’t be easy as you have to manually search and redact all the sensitive information from all your playbooks, and as we know manual procedure is not always error prone. You might ‘forget’ to remove some of the paswords.

One solution for this is a password vault to hold all your sensitive data, and Ansible provides a utitility called ansible-vault to create this encrypted file and the data can be extracted when running your playbooks with a single option. This is equivalent to Chef’s data bag.

In this blog post, I will share with you how to use a secret key file to protect sensitive data in Ansible with ansible-vault utility. The simplest use case is to protect the encrypted file with a password or passphrase, but that is not convinient as you have to type the password everytime you run a playbook and is not as strong as a key file with hundreds or thousands of random characters. Thus the steps below describe only the procedure for setting up a secret key file rather than a password protected encrypted file. Let us get started.

The first step is to generate a key file containing a random list of characters –

#openssl rand -base64 512 |xargs > /opt/ansible/vaultkey

Create or initialize the vault with the key file generated above –

#ansible-vault create --vault-password-file=/opt/ansible/vaultkey /opt/ansible/lamp/group_vars/dbservers.yml

Populate your vault, refer to Ansible documentation on the format of the vault file –

#ansible-vault edit --vault-password-file=/opt/ansible/vaultkey /opt/ansible/lamp/group_vars/dbservers.yml

You can view the contents by replacing ‘edit’ with ‘view’ –

#ansible-vault view --vault-password-file=/opt/ansible/vaultkey /opt/ansible/lamp/group_vars/dbservers.yml

That is it, you have a secret key file to protect and encrypt a YAML file containing all your sensitive variables to be used in your ansible playbooks.

There comes a time though when you have to change the secret key file, say an admin leaves the company after winning the Mega jackbot lottery 🙂 We have to generate a new key file and rekey the encrypted file as soon as possible –

Generate a new key file –

#openssl rand -base64 512 |xargs > /opt/ansible/

Rekey to new key file –

#ansible-vault rekey --new-vault-password-file=/opt/ansible/ --vault-password-file=/opt/ansible/vaultkey
Rekey successful

Verify –

#ansible-vault view --vault-password-file=/opt/ansible/ /opt/ansible/lamp/group_vars/dbservers.yml

Last but not least, make sure the secret key file is well protected and is readable only by the owner.

#chmod 600 /opt/ansible/

Finally, you can use the vault with ansible-playbook. In this case, I am running it against site.yml which is a master playbook to setup a LAMP cluster in AWS (pulling the AWS instances using dynamic inventory script) –

#ansible-playbook -i /usr/local/bin/ site.yml --vault-password-file /opt/ansible/