I’m a big fan of automation and configuration management. It makes life a lot easier when it comes to installing and configuring (whatever there is you’re installing and configuring), and also less error prone. And that is where configuration management tools like Ansible, Puppet, Chef & Saltstack comes into play. They help you enforce state on your hosts, which makes keeping things in line easy. You just update your manifest (in the Puppet-case) and soon after the agent on the managed hosts checks in with the master, all your hosts have applied the change. It doesn’t matter if you’re managing 1, 50, 500 or 5000 hosts, you just make the change once and the tool does all the rest. I mean, whats not to like about that?
We’re using Puppet at work and I’ve also been using it in the home lab for a while. In the lab mostly as a part of setting up new VM’s, where they get kickstarted with a minimal core/base-install and handed off to Puppet to set up the rest, a default user, configure ntp, install a few nice-to-have packages etc.
If I then want to install a single instance of Oracle, I could use a rpm-packaged database server installs (or use biemond-oradb which is available on Puppet Forge). But beyond a single instance it gets increasingly difficult to use rpm’s. I also like to keep the number of ways to install something to a minimum.
I also imagine orchestrating something like a RAC install with puppet is no easy task. I’m sure it can be done, but I’m certainly not Puppet savvy enough to do it.
So things like RAC have always been pretty much a manual effort. I’ve been working with RAC for quite a long time so actually getting it installed is not hard, it just takes time to configure everything and it gets tedious after a while. And when you do things manually, there is always the possibility that you stuff things up.
Ansible is an agentless configuration management and orchestration tool, and it’s awesome!
- It is push based (as opposed to Puppet which is pull based). However, there is also a pull-based variant of Ansible.
- It doesn’t need an agent installed on the managed host
- It uses ssh to communicate and interact with the managed hosts.
- It uses ordered execution, meaning tasks get executed in the exact order you specify them. No need to set up dependencies between the different tasks.
- It is really easy to get started with.
- It runs in 2 modes: To run ad hoc commands (like restarting a service on x number of nodes), or in ‘playbook’ mode where you have a number of tasks that make up a play (like installing RAC )
Ansible needs a Linux controlmachine, which is where you run your playbooks/ad-hoc commands. So installing Ansible on your controlmachine is as easy as:
- Download and enable the epel repo (if you’re using a rhel-based system)
- yum install ansible
There are also other ways to install Ansible, and they’re all covered in the documentation.
I’ve been tinkering with Ansible over the summer and now I’ve got a bunch of roles that can be used to install Oracle.
At the moment the roles supports Single instance (with or without Grid Infrastructure) and a full-blown RAC installation.
So now, if I want to set up a new RAC, its (pretty much) as easy as:
ansible-playbook runtask.yml -e "file=deploy-ora-rac-vm.yml" (Yeah, I also use Ansible to deploy VM's) ansible-playbook full-rac-install.yml
Then I just sit back and wait and about an hour later I’ve got a fully configured cluster including (at the moment) 2 databases.
Anyway, all my code is available on Github. Just do a:
git clone http://github.com/oravirt/ansible-oracle.git
and you’re off to the races.
In the next blog-posts we’ll take a closer look at the playbooks.