Oracle Database Automation with Ansible AWX

In the video below I demonstrate how a simple Ansible playbook can be used to automate the cloning of multiple Oracle databases in parallel.

In the demo I use the AWX Web UI to run the playbook, the AWX project is an Open Source community project sponsored by RedHat, it can be considered the ‘bleed-in edge’ of RedHat Ansible Tower.

AWX is designed to be fast moving and is where the development takes place before being hardened and making it’s way into the enterprise ready RedHat supported Ansible Tower solution.

AWX is great from lab work, but for all Production workloads I would strongly recommend that Ansible Tower is considered.

Pure Code Developer Community

Visit the Pure Code Developer Community and click on the ‘Ansible Playbook Examples’ card to be directed to the public GitHub repository, you will find this and other Oracle playbook examples.


Getting started with Ansible and Windows


I spend most of my time working with Linux but occasionally I come across Oracle on Windows, so I thought it’s about time that I tried my hand at using Ansible on Windows.

Ansible on Windows

You can not currently run Ansible on Windows, but you can manage Windows servers from a Linux or Mac Ansible control machine.

Ansible uses ‘SSH’ to manage Linux servers, on Windows Ansible requires ‘winRM’ Windows Remote Manager services. The Ansible docs details prerequisites, which include PowerShell v3 and .Net 4.0 and winRM, the steps to set-up winRM can be found here.

If you read my previous Blog Post Getting started with Ansible and Oracle you will have seen me use ‘ping’ to check connectivity to a Linux server, to do this in a Windows environment we use ‘win_ping’ module via the -m option.

You can see that the Ansible ‘ping’ and ‘win_ping’ both return the familiar ‘pong’ message, indicating good connectivity.

Ok, that’s pretty cool, now let’s try running the Windows ‘whoami.exe’ using the ‘win_command’ module.

And a quick ‘Hello World’ test via PowerShell and the ‘win_shell’ module.


Next steps, create some Windows playbooks and test, but that’s for another Blog.

Ansible 2.6 Now available

At the beginning of July, Ansible 2.6 was released, this release depreciates a few commands, fixes some issues and extends Cloud support for Amazon, Azure & Google.

Ansible 2.6 also includes a few new and updated Pure Storage FlashArray and for the first time FlashBlade modules:

Pure Storage FlashArray

purefa_host – Enable mixed protocol hosts
purefa_hg – Modify existing hostgroups
purefa_ds – Manage Directory Service configuration
purefa_facts – Gather Facts information
purefa_pgsnap – Manage Protection Group snapshots

Pure Storage FlashBlade

purefb_fs – Manage filessystems
purefb_snap – Manage filesystem Snapshots


Pure Code Developer Community

Visit the Pure Code Developer Community and click on the ‘Ansible Playbook Examples’ card to be directed to the public GitHub repository for example playbooks.

Oracle 12c Multi-database refresh with Ansible

In this Blog post I will share another short video demonstrating how storage data services can be used to perform many common data management tasks using simply scripting, DevOPS automation tools and Pure Storage REST API’s .

Oracle 12c multiple databases clones with Ansible

Before we jump into the demonstration let me detail my architecture and explain what you are going to see, first the Architecture.

The Architecture

z-oracle will be used as my Ansible control machine
z-oracle1 is where my production Oracle 12c database is hosted
z-oracle2 thru to z-oracle7 are my development / test database servers.
FlashArray will be used to deliver the storage data services.Ansible_Demo

The Ansible Playbook

The database_clone Ansible playbook performs the following steps:

  1. Performs crash-consistent storage snapshot of production database using REST API.
    1. The storage snapshot is instant, has no impact to the running production database, and does not require any changes to production server or database configuration.

  2. Shutdown non-production database(s) and unmount database filesystems.
  3. Refresh non-production volume(s) from latest storage snapshot.
  4. Mount database filesystems and start database(s).
    1. At this point the non-production database(s) are exact copies of the production database with the same name as production but consuming no space.

  5. Rename non-Production database, datafiles and directories.

If you have watched the video you will have seen that the 6 non-production databases have all been refreshed from production in less than 2 1/2 minutes from a single Ansible playbook.

Visit to see more Ansible examples and also find examples for other DevOPs tools and languages including Python, PowerShell, Puppet…

Getting started with Ansible and Oracle


In my previous post An introduction to Ansible I shared some reasons why companies are adopting Ansible and described some of the advantages of using Ansible over other configuration management tools.

Now we know what Ansible is, let’s start using it.

Setting up an Ansible Control Machine

The simplest and quickest way to get up and running with Ansible is to use Vagrant to create a virtual machine. Vagrant ships with out of the box support for VirtualBox, Hyper-V and Docker. Vagrant supports other providers e.g. VMware but these are licenceable

So even though I mainly use VMware Fusion on my MacBook I used the links above to install Vagrant and the excellent Oracle VirtualBox to avoid any licensing requirements.

Using Vagrant

Run the following commands to create a Vagrantfile for an Ubuntu Vagrant machine.
$ mkdir ansible_oracle
$ cd ansible_oracle
$ vagrant init ubuntu/trusty64

A `Vagrantfile` has been placed in this directory. You are now ready to `vagrant up` your first virtual environment! Please read the comments in the Vagrantfile as well as documentation on `` for more information on using Vagrant.

$ vagrant up
You should now be able to SSH into your Ubuntu VM using ‘vagrant ssh’, however before we try and connect to our new VM let’s check the status of all the local Vagrant machines using the following:
$ vagrant global-status

id       name    provider   state    directory
a1995ac  default virtualbox running  /Users/ronekins/ansible_oracle

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
“vagrant destroy 1a2b3c4d”

$ vagrant status a1995ac
Current machine states:

default running (virtualbox)

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

$ vagrant ssh
If all has gone well you should be presented with your Ubuntu virtual machine.

Useful vagrant machine (vm) commands

destroy       : stops and deletes all traces of the vm 
global-status : outputs status Vagrant env's for this user 
halt          : stops the vm 
init          : initialises a new Vagrant environment 
provision     : provisions the vm 
reload        : restarts vm, loads new Vagrantfile config 
resume        : resume a suspended vm 
snapshot      : manages snapshots, saving, restoring, etc. 
ssh           : connects to vm via SSH 
status        : outputs status of the vm 
suspend       : suspends the vm 
up            : starts and provisions the vm

Ansible Installation

$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible

Update local host file

Add the IP address and database server names to your local host file.
$ sudo vi /etc/hosts

Getting Started

Create Ansible configuration file

$ vi ansible.cfg
hostfile = hosts

Create Ansible host file

In the host file we can specify that we want ansible to default to the ‘oracle’ user, the first entry is a server alias, in the example below I have kept it the same as the server name but it can be useful if you have cryptic host names or want to refer to the server by it’s database or application name.
$ vi hosts
z-oracle         ansible_host=z-oracle        ansible_user=oracle
z-oracle-dr  ansible_host=z-oracle-dr  ansible_user=oracle

Ansible Ping Test

Now let’s try using the Ansible ping module to try to connect to our database server and verify a usable version of python, the ping module will return ‘pong’ on success.
$ ansible all -m ping

Both servers will fail returning UNREACHABLE! as the ssh connection failed, to fix this add a public key to the database servers ‘authorized_keys’file.

Generating RSA Keys

Before we can use password-less SSH we need to create a pair of private and public RSA keys for our Ansible control machine.

$ cd ~/.ssh
$ ssh-keygen -t rsa
$ cat

‘Copy’ the into your client buffer and ssh onto the database servers as the ‘oracle’, cd to the .ssh directory and ‘paste’ the public key into the ‘authorized_keys’ file.

$ cd ~/.ssh
$ vi authorised_keys

Now return to your Ansible control machine to repeat the Ansible Ping Tests.

Ansible Ping Part II

Ok, now we are ready to check connectivity, first lets trying using the database server names individually.
That was great, but as we defined a group ‘dbservers’ we can also perform a ‘ping’ test using the group name as we may want to perform an ansible play against a group of servers e.g. Production, Development, Test etc..

Very cool, if required you can use the ‘all’ option to run against all entries in the host file.

In my next blog post we will start to use our Ubuntu Ansible control machine to interact with our database servers.

An introduction to Ansible

Why this Blog

Over the last couple of years I have found myself increasingly working with DevOps teams and being exposed to the tools and techniques being adopted. However speaking to other DBA’s and Architects it appears that for many it’s still a bit of a ‘Dark Art’, so I thought it was about time I shared some the knowledge over a series of DevOps focused Blogs posts.

Why is Ansible, Ansible ?

The term Ansible is a Science Fiction reference for a ficitonal communications device that can transfer information faster than the speed of light.

The author Ursula LeGuin invented the concept in her 1966 book ‘Rocannon’s World’, subsequently other SciFi authors have borrowed the term.

Only for a moment, when he had located the control room and found the ansible and sat down before it, did he permit his mind-sense to drift over to the ship that sat east of this one. There he picked up a vivid sensation of a dubious hand hovering over a white Bishop. …

As his fingers (left hand only, awkwardly) struck each key, the letter appeared simultaneously on a small black screen in a room in a city on a planet eight lightyears distant:

From Rocannon’s World, by Ursula LeGuin.

Michael DeHaan the creator of Ansible took inspiration for the name Ansible from the book ‘Enders Game’ by Orson Scott Card (note to self must read book / watch the film) in the book Ansible is used to control a large number of remote ships at once, over large distances.  From now on whenever I mention Ansible it will be to control remote servers not ships, however it would be useful to be able to control my Elite Dangerous craft remotely.

What is Ansible ?

Ansible is often lumped into the DevOps tool category of ‘Configuration Management’ and compared to Puppet, Chef & Salt. The term ‘Configuration Management’ is generally used to describe the management of the state of IT infrastructure, which can include servers, storage arrays and databases etc…

When you need to deploy configuration change across multiple platforms ‘Orchestration’ is often required to ensure the correct sequence of events, e.g. you may need to configure storage volumes, Unix mount points all before you can start a database service. Ansible is pretty good a conductor, orchestrating actions across multiple servers.

Why use Ansible

Ansible and Salt both use a ‘Push’ method of communication that does not not require any agents to be installed on remote servers. Ansible’s only requirements are SSH connectivity to the remote servers and for the servers to have Python 2.5 installed. I have not yet had the opportunity to take Salt for a test ride, so I can’t comment on it’s requirements.

Puppet and Chef have taken a ‘Pull-based’ approach, where agents installed on the remote servers periodically check in with a central server and pull down configuration information.

The ‘Push-based’ approach has a significant advantage over ‘Pull-based’ solutions as you can control when a configuration change is implemented rather than having to wait for a timer to expire in a ‘Pull-based’ solution.

My next Blog Post will be ‘Getting Started with Ansible and Oracle’.

Hope to get it out very soon, if you want to know when it’s ready use the below to follow me.