Managing an utility on OpenStack presents a bunch of challenges for the system administrator, and discovering methods to scale back complexity and produce consistency are key components to attaining success. By utilizing Ansible, an agentless IT automation know-how, a system administrator can create Ansible playbooks that present consistency and cut back complexity.
OpenStack supplies a wealthy API to handle sources that has led to the creation of dozens of Ansible modules that may simply match into any automation workflow. Combined with the power to automate duties in OpenStack cases, an operator can work each inside and out to coordinate advanced operations in opposition to an surroundings.
“Day one” operations seek advice from duties which can be executed in the course of the preliminary configuration and deployment of an surroundings. The index of OpenStack modules for Ansible lists most of the widespread modules used to finish duties throughout day one. Creating all method of sources, reminiscent of networks, volumes, and cases are coated. “Day two” offers with what occurs subsequent:
- How will upgrades occur?
- How are backups maintained?
- How does the surroundings scale up with demand?
Ansible can simply deal with these use instances.
For instance, contemplate a cluster of net servers that want to be upgraded, all sitting behind an OpenStack load balancer. With the power to handle each the infrastructure and duties throughout the VMs themselves, an operator can make sure the sequence of occasions executed at all times occurs in a specific order. Here is an easy instance of a playbook to carry out a rolling improve:
- hosts: net
gather_facts: true
consumer: centos
serial: 1 # ensures just one server will replace/reboot at a time
duties:
- title: test for pending updates
yum:
record: updates
register: yum_update # test if there are updates earlier than going any additional
- block:
- title: take away net server from pool
os_member:
state: absent
title: ' ansible_hostname '
pool: weblb_80_pool
delegate_to: localhost
- title: replace packages
bundle:
title: '*'
state: newest
turn out to be: true
- title: reboot server
shell: sleep 5 && reboot &
async: 1
ballot: zero
- title: anticipate server
wait_for_connection:
connect_timeout: 20
sleep: 5
delay: 5
timeout: 600
turn out to be: true
- title: put server again in pool
os_member:
state: current
title: ' ansible_hostname '
pool: weblb_80_pool
handle: ''
protocol_port: 80
delegate_to: localhost
when:
- yum_update.outcomes | size > zero # solely execute the block if there are updates
This playbook first checks to see whether or not there are any updates to use. If so, the playbook removes the node from the pool, applies the updates, and reboots the node. Once the node is again on-line, it will get added again into the pool. The Ansible playbook makes use of the serial key phrase to make sure just one node is faraway from the pool at a time.
If a database is working within the OpenStack cloud, sometimes a backup should be restored—both to refresh some check information or maybe within the occasion of an information corruption incident. Orchestrating duties between the database server and Cinder is definitely achieved with Ansible:
- hosts: db
gather_facts: true
consumer: centos
duties:
- title: cease database
systemd:
title: mongod
state: stopped
turn out to be: true
- title: unmount db quantity
mount:
path: /var/lib/mongodb
state: unmounted
turn out to be: true
- title: detach quantity from server
os_server_volume:
state: absent
server: db0
quantity: dbvol
delegate_to: localhost
- title: restore cinder backup
command: openstack quantity backup restore dbvol_backup dbvol
delegate_to: localhost
register: vol_restore
failed_when:
- vol_restore.rc > zero
- "'VolumeBackupsRestore' not in vol_restore.stderr"
- title: anticipate restore to complete
command: openstack quantity present -c standing -f worth dbvol
register: restore_progress
till: restore_progress.stdout is search("available")
retries: 60
delay: 5
delegate_to: localhost
- title: reattach quantity to server
os_server_volume:
state: current
server: db0
quantity: dbvol
machine: /dev/vdb
delegate_to: localhost
- title: mount db quantity
mount:
path: /var/lib/mongodb
state: mounted
src: LABEL=dbvol
fstype: xfs
turn out to be: true
- title: begin database
systemd:
title: mongod
state: began
turn out to be: true
Looking intently on the playbook, you will have observed that the restore is completed by way of the OpenStack command line and never a correct Ansible module. In some instances, a module for a process may not exist, however Ansible is versatile sufficient to permit calling arbitrary instructions inside a playbook till a module is developed. Feel like you possibly can write the lacking module? Consider creating it by contributing to the Ansible project.
These are simply a few day-two operations a system administrator might have to orchestrate of their cloud. Roger Lopez and I’ll provide a hands-on lab at OpenStack Summit in Berlin with real-world eventualities and related Ansible playbooks to automate them. We’ll additionally add our examples and supplies to GitHub the week of the convention for the good thing about anybody who cannot attend.
Roger Lopez and David Critch will current Simplifying Day Two Operations with Ansible (A Hands-on Lab) on the OpenStack Summit, November 13-15 in Berlin.
