Custom webApp DPK Role

In an earlier post, I talked about the site.pp file and how the DPK uses that file to determine what software to install. I covered the roles used by the DPK and in this post we’re going to create a custom role.

One of my criticisms of the DPK is the lack of a webApp role. You can install a scheduler, app server, web server, appBatch server, but not a webApp server. We are consolidating our web and app servers onto a single machine and I wanted to use the DPK to install the software and the initial configuration. The delivered roles didn’t work, so we created our own webApp role for the DPK.

pt_tools_webapp

To start, I copied the delivered role file pt_tools_midtier.pp and named it pt_tools_webapp.pp. In the pt_tools_webapp.pp file I removed the lines:

contain ::pt_profile::pt_prcs

contain ::pt_profile::pt_tools_preboot_config
contain ::pt_profile::pt_tools_postboot_config

Class['::pt_profile::pt_prcs'] ->
Class['::pt_profile::pt_tools_preboot_config'] ->
Class['::pt_profile::pt_tools_postboot_config'] ->

Remove the Class[] lines from both sections of the manifest.

The line Class['::pt_profile::pt_prcs'] -> calls the profile that will create/configure the process scheduler. By removing this line, Puppet will skip the process scheduler creation step.

I also removed the two lines that call the ACM: Class['::pt_profile::pt_tools_xxxboot_config']. When we built our servers, the database was already configured. I didn’t want to the ACM to run when built the web and app servers. We’ll run the ACM on our own schedule. If we left these two lines in, the ACM would run every time we built a new server with this role.

Last, update the class name to the new role: class pt_role::pt_tools_webapp inherits pt_role::pt_base {, and the notification to notify { "Applying pt_role::pt_tools_webapp": }. (I also removed the checks for env_type.)

This is what our role pt_tools_webapp.pp file looks likes:

class pt_role::pt_tools_webapp inherits pt_role::pt_base {
  notify { "Applying pt_role::pt_tools_webapp": }

  $ensure   = hiera('ensure')

  contain ::pt_profile::pt_tools_deployment
  contain ::pt_profile::pt_psft_environment
  contain ::pt_profile::pt_appserver
  contain ::pt_profile::pt_pia
  contain ::pt_profile::pt_samba
  contain ::pt_profile::pt_source_details

  if $ensure == present {
    contain ::pt_profile::pt_domain_boot

    Class['::pt_profile::pt_system'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_appserver'] ->
    Class['::pt_profile::pt_pia'] ->
    Class['::pt_profile::pt_samba'] ->
    Class['::pt_profile::pt_domain_boot'] ->
    Class['::pt_profile::pt_source_details']
  }
  elsif $ensure == absent {
    Class['::pt_profile::pt_source_details'] ->
    Class['::pt_profile::pt_samba'] ->
    Class['::pt_profile::pt_pia'] ->
    Class['::pt_profile::pt_appserver'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_system']
  }
}

To use the new role, change the site.pp file to this:

node default {
  include ::pt_role::pt_tools_webapp
}

Then run puppet apply site.pp to install and create your web-app servers.

There is a few bug with this custom role, but it is based on assumptions in the DPK. The pt_profile::pt_domain_boot profile doesn’t know about our webapp role. If you leave the pt_domain_boot profile in the role the DPK will attempt to start (or stop) a process scheduler domain. Since we don’t have one, you’ll see some errors in the output when you run puppet apply site.pp. You can ignore these, or you can modify the pt_domain_boot.pp manifest under etc\modules\pt_profile\pt_domain_boot.pp. I chose to ignore the errors.

We also added a new variable to the psft_customizations.yaml file called server_type:. We used server_type: webApp for our webApp servers, and then we can use that value in other Puppet manifests for any server-specific logic.

If you want to try this, keep in mind that the custom role won’t be supported by Oracle. It helps to have a basic understanding of Puppet when creating the roles, but this is also a great way to start learning Puppet and the DPK.

I also created an Idea on the Oracle Community Lifecycle Management site for the DPK webApp role. If you would like to see this supported in the DPK, go vote for it! I also posted the custom code to GitHub if you want suggest any changes.