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:

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.)

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.

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

This will be displayed in a monospaced font. The first four
spaces will be stripped off, but all other whitespace
will be preserved.
Markdown is turned off in code blocks:
[This is not a link](http://example.com)