Puppet code for Oracle installation

We have done our best to make it as easy as possible to use Puppet to change your “stem-cell” system into a running Oracle database. Let’s look at some of the Puppet code needed to do this.

In the editor tab, go to the directory hierdata\nodes and open the file ora19.playground.enterprisemodules.com.yaml. This file contains all the node-specific data.

At the top, you see:

role:    role::database

This hiera definition tells Puppet that for this node, node ora19.enterprisemodules.com, we want to apply the Puppet class role::database.

The role role::database

Let’s see what this Puppet class is doing for us. In the editor tab, go to the directory modules\role\manifests and open the file database.pp. For your convenience, I have included the contents here as well.

class role::database
{
  contain ::profile::base
  contain ::ora_profile::database

  Class['::profile::base'] -> Class['::ora_profile::database']
}

As you can see, this role class contains two other classes (contain is a special sort of include). The ::profile::base class is what we call: the base profile. A base profile contains all Puppet definitions you would like to apply to every node in your organization. It includes all standard settings you want to apply to your system, no matter what.

The second include is the ::ora_profile::database class. This Puppet class is where all the magic happens! It transforms this node into an Oracle database.

Pretty easy, right? Now, Let’s see it in action!

Ensure prerequisites

In a normal situation, the ora_profile Puppet class would silently take care of all prerequisites for you. For teaching purposes, however, we have disabled this.

In the editor tab, go to the directory hierdata\nodes and open the file ora19.playground.enterprisemodules.com.yaml. This file contains all the node-specific data.

In tis file you see this:

ora_profile::database::limits:           skip
ora_profile::database::groups_and_users: skip
ora_profile::database::packages:         skip
ora_profile::database::firewall:         skip
ora_profile::database::tmpfiles:         skip
ora_profile::database::db_software:      skip

These are the hiera settings that tell ora_profile NOT to execute the steps involving: limits, groups_and_users, etc. (as explained in the first paragraph).

First Puppet run

With all the skips in place, let’s run Puppet and see what happens. Jump back to the terminal tab en execute the command below:

puppet apply site.pp 

Well, that didn’t do a lot. It installed two packages and copied some files.

Notice: Compiled catalog for ora19.playground.enterprisemodules.com in environment production in 0.26 seconds
Notice: /Stage[setup]/Easy_type::License::Available/File[/etc/puppetlabs/puppet/em_license]/ensure: created
Notice: /Stage[setup]/Easy_type::License::Available/File[/etc/puppetlabs/puppet/em_license/.gitkeep]/ensure: defined content as '{md5}d41d8cd98f00b204e9800998ecf8427e'
Notice: /Stage[main]/Profile::Base::Docker/Package[mlocate]/ensure: created
Notice: /Stage[main]/Profile::Base::Docker/Package[unzip]/ensure: created
Notice: Applied catalog in 8.80 seconds

What it actually did, was executing only the base profile. The base profile for this tutorial is kept very minimal, for obvious reasons.

Re-enable all prerequisite steps.

In this next step, we are going to enable some of the skipped definitions in the hierarchy configuration. To do this, open the node yaml again (in the editor tab). Navigate to the first block (lines 11 to 16) of skips and remove or comment out all lines except the db_software one (line 16). No need to save the file, we’ll do that for you in the background.

#
#ora_profile::database::limits:           skip
#ora_profile::database::groups_and_users: skip
#ora_profile::database::packages:         skip
#ora_profile::database::firewall:         skip
#ora_profile::database::tmpfiles:         skip
ora_profile::database::db_software:       skip
#

Re-run Puppet

So, now ora_profile will execute more of its regular steps. Let’s see what a re-run of Puppet provides us.xs

puppet apply site.pp 

Wow, that’s a lot more. What Puppet does now is:

• Configuring all sysctl settings
• Configuring all security limits
• Installing required packages
• Creating the required Oracle users and groups
• Managing tmpfile settings for Oracle named pipes

And with that, all needed prerequisites for a successful Oracle database installation are fulfilled

Next up: installing the Oracle software itself.

Install the Oracle software

With all of the prerequisites done, it is time to install some Oracle software.

In the editor tab, go to the directory hierdata\nodes and open the file ora19.playground.enterprisemodules.com.yaml. This file contains all the node-specific data.

Let’s comment out the skip for the step ora_profile::database::db_software as well now (line 16). Meaning: next Puppet run, DO execute the software installation.
Your hiera should look something like this now:

#
#ora_profile::database::limits:           skip
#ora_profile::database::groups_and_users: skip
#ora_profile::database::packages:         skip
#ora_profile::database::firewall:         skip
#ora_profile::database::tmpfiles:         skip
#ora_profile::database::db_software:      skip
#

Re-run Puppet

Let’s see what Puppet has got in store for us now and re-run Puppet.

puppet apply site.pp 

Be aware: installing the Oracle software can take some time. On average a Puppet run will take two to four minutes.

So, now ora_profile will execute all of the steps required to install the Oracle software. Since it has already taken care of the prerequisites in the previous Puppet run, it will detect everything is already in place and report no additional changes on this.

For the actual Oracle software installation, it executes these steps:
1) Create all required directories
2) Fetch the oracle software zip from a file server and unzip it.
3) Create an auto-answer file whit all specified settings
4) Run the universal installer.
5) Run root.sh
6) Cleanup

Re-run Puppet and check idempotency

What happens now if we run Puppet again?

puppet apply site.pp 

Puppet detects everything is in its desired state (configured as described in your Puppet manifests and hierarchy settings) and changes nothing. It is idempotent.

Next up: Create a database.

Create the database

Last, but certainly not least, we will have to ensure the database is available to the users.

In the editor tab, go to the directory hierdata\nodes and open the file ora19.playground.enterprisemodules.com.yaml. This file contains all the node-specific data.

WIn this playground, we’ll skip the installation of Oracle patches and focus on configuring the inside of the database. If you want to play around with patching your database, we can recommend this playground (an have a link to it here)

If you take a look at the third block of settings (lines 25 through 32), they should like this for now:

ora_profile::database::db_definition:  skip
ora_profile::database::db_listener:    skip
ora_profile::database::db_init_params: skip
ora_profile::database::db_services:    skip
ora_profile::database::db_tablespaces: skip
ora_profile::database::db_profiles:    skip
ora_profile::database::db_users:       skip
ora_profile::database::db_startup:     skip

This tell’s Puppet to skip all database steps. Like I explained before, this is here for teaching purposes. Let’s remove or comment out all of these skips, so Puppet will apply a full manifest that ensures the creation of the database and other Database objects.

Make sure yaml file now looks like this:

#ora_profile::database::db_definition:  skip
#ora_profile::database::db_listener:    skip
#ora_profile::database::db_init_params: skip
#ora_profile::database::db_services:    skip
#ora_profile::database::db_tablespaces: skip
#ora_profile::database::db_profiles:    skip
#ora_profile::database::db_users:       skip
#ora_profile::database::db_startup:     skip
#

Re-run Puppet

Let’s see what Puppet has in store for us now, as we re-run Puppet via the terminal window:

puppet apply site.pp 

Be aware that creating a database, in general, is a time-consuming job (with our without Puppet) and is a test of your patience. In this playground a Puppet run might take up to 35 minutes to complete, ensuring the database is ready.

After this Puppet run, you’ll see that database DB01 has been created and is running on your playground system.

Re-run Puppet and check idempotency

And again, let’s see what happens if we run Puppet one last time:

puppet apply site.pp 

Puppet detects everything is at its desired state, as described in your Puppet manifests and hierarchy settings. No changes will be done to the system. Another example of the built-in idempotency.

Next up: Customising your database

You like it?

Do you like what you see here and want to test this on your own infrastructure? No problem. You can sign up for a free trial.

If you have any questions, don’t hesitate to contact us.