Using the DPK to install only WebLogic
Jul 12, 2016Dan Iverson
With the Deployment Packages, you can install an entire PeopleSoft system. But what if you want to install just one component? You can install the PIA role, but you get WebLogic, Tuxedo, Java, and a PIA domian. In this post, we’ll show how to leverage the DPK with custom Puppet manifests and install only WebLogic (and Java) on a server.
You will need to the DPK Puppet files on the server. Run the bootstrap script and stop at the “Default Initialization” question so nothing gets installed. You can use any parameters you want for the bootstrap script. We’ll be ignoring the site.pp
file and using a new manifest file.
I’ll document the custom manifests in this post, but if you want to download the code you can grab it from GitHub. Copy the files in the project into the corresponding folders under the puppet\etc
folder on your machine.
psft_customizations.yaml Updates
For the WebLogic install, I wanted the software to install in the e:/oracle
folder. I added/updated these values in my psft_customizations.yaml
file:
oracle_base: e:/oracle
jdk_location: "%{hiera('oracle_base')}/jdk1.7.0_95"
weblogic_location: "%{hiera('oracle_base')}/bea"
You don’t need to use oracle_base
and can ignore these changes if you want WebLogic installed to the default location.
weblogic.pp Manifest
Create a new manfiest under etc\manfiests
(or copy the site.pp
file) and name it weblogic.pp
. In the weblogic.pp
manifest, we are doing two things:
- Create the
oracle_base
folder (the DPK will fail if the base folder doesn’t exist) - Call a custom DPK role (we’ll create this next)
Here is the weblogic.pp
file:
# Verify the Oracle Base folder is present - DPK doesn't like it when the base folder isn't created.
file { hiera('oracle_base') :
ensure => 'directory',
}
# Call custom profile to install WebLogic (and JDK)
node default {
include ::pt_role::pt_tools_weblogic
}
If you’ve looked at the site.pp
file you’ll recognize the second section. The first part of the file is Puppet code to create a folder if it doesn’t exist.
If you aren’t familiar with Puppet, the Puppet CookBook is a good place to get familiar with writing manifests.
WebLogic DPK Role
A new DPK role file was created under etc\modules\pt_role\manifests
called pt_tools_weblogic.pp
. From the post on the sites.pp
file, we introduced the idea of DPK roles. The best practice is to only have one role per machine. For the WebLogic-only install, we’ll create a new role so its clear that this server is only running WebLogic.
class pt_role::pt_tools_weblogic inherits pt_role::pt_base {
notify { "Applying pt_role::pt_tools_weblogic": }
$ensure = hiera('ensure')
contain ::pt_profile::pt_weblogic
Class['::pt_profile::pt_weblogic']
}
The role file uses the ensure
attribute from the defaults.yaml
file to determine if Puppet should install or remove WebLogic. The default value is to install (ensure = present
).
Next, the role calls a new profile called pt_profile::pt_weblogic
. Let’s create that file net.
WebLogic DPK Profile
A DPK profile handles the configuration lookup from Hiera and preparing Puppet for the installation (or removal). Our custom profile grabs the installation directory (oracle_base
and weblogic_location
) from the psft_customizations.yaml
file. WebLogic requires Java too, so we configure that in the profile as well.
Create a new profile under etc\modules\pt_profile\manifests
and call it pt_weblogic.pp
.
# Custom Profile to prepare for WebLogic installation
class pt_profile::pt_weblogic {
notify { "Applying pt_profile::pt_weblogic": }
## Hiera lookups
$ensure = hiera('ensure')
$env_type = hiera('env_type')
$tools_archive_location = hiera('archive_location')
$jdk_hiera = hiera('jdk')
$jdk_location = $jdk_hiera['location']
$jdk_remove_value = $jdk_hiera['remove']
if $jdk_remove_value == false {
$jdk_remove = false
}
else {
$jdk_remove = true
}
notice ("JDK remove is ${jdk_remove}")
$weblogic_hiera = hiera('weblogic')
$weblogic_location = $weblogic_hiera['location']
$weblogic_remove_value = $weblogic_hiera['remove']
if $weblogic_remove_value == false {
$weblogic_remove = false
}
else {
$weblogic_remove = true
}
notice ("Weblogic remove is ${weblogic_remove}")
$redeploy = hiera('redeploy', false)
class { '::pt_setup::weblogic_deployment':
ensure => $ensure,
tools_archive_location => $tools_archive_location,
inventory_location => $inventory_location,
jdk_location => $jdk_location,
jdk_remove => $jdk_remove,
weblogic_location => $weblogic_location,
weblogic_remove => $weblogic_remove,
redeploy => $redeploy,
}
contain ::pt_setup::weblogic_deployment
}
WebLogic DPK Deployment
Finally, we’ll call the Puppet code to install Java and WebLogic! We are using two DPK types in this manifest:
pt_deploy_jdk
pt_deploy_weblogic
This is why the DPK needs to be installed before using these manifests. If the DPK is missing, these calls will fail (and so will some of the hiera lookups). The deployment manifest is under the folder etc\modules\pt_setup\manifests
. Create the file weblogic_deployment.pp
from the code below or from the GitHub project.
# Custom Puppet Class to deploy WebLogic using the DPK
class pt_setup::weblogic_deployment (
$ensure = present,
$deploy_pshome_only = false,
$tools_archive_location = undef,
$tools_install_user = undef,
$tools_install_group = undef,
$oracle_install_user = undef,
$oracle_install_group = undef,
$db_type = undef,
$pshome_location = undef,
$pshome_remove = true,
$inventory_location = undef,
$oracleclient_location = undef,
$oracleclient_remove = true,
$jdk_location = undef,
$jdk_remove = true,
$weblogic_location = undef,
$weblogic_remove = true,
$tuxedo_location = undef,
$tuxedo_remove = true,
$ohs_location = undef,
$ohs_remove = true,
$redeploy = false,
) {
notice ("Applying pt_setup::weblogic_deployment")
$jdk_tag = 'jdk'
$weblogic_tag = 'weblogic'
$jdk_archive_file = get_matched_file($tools_archive_location, $jdk_tag)
if $jdk_archive_file == '' {
fail("Unable to locate archive (tgz) file for JDK in ${tools_archive_location}")
}
$weblogic_archive_file = get_matched_file($tools_archive_location, $weblogic_tag)
if $weblogic_archive_file == '' {
fail("Unable to locate archive (tgz) file for Weblogic in ${tools_archive_location}")
}
$jdk_patches = hiera('jdk_patches', '')
if ($jdk_patches) and ($jdk_patches != '') {
notice ("JDK patches exists")
$jdk_patches_list = values($jdk_patches)
}
else {
notice ("JDK patches does not exists")
$jdk_patches_list = undef
}
pt_deploy_jdk { $jdk_tag:
ensure => $ensure,
deploy_user => $tools_install_user,
deploy_user_group => $tools_install_group,
archive_file => $jdk_archive_file,
deploy_location => $jdk_location,
redeploy => $redeploy,
remove => $jdk_remove,
patch_list => $jdk_patches_list,
}
$weblogic_patches = hiera('weblogic_patches', '')
if ($weblogic_patches) and ($weblogic_patches != '') {
notice ("Weblogic patches exists")
$weblogic_patches_list = values($weblogic_patches)
}
pt_deploy_weblogic { $weblogic_tag:
ensure => $ensure,
deploy_user => $tools_install_user,
deploy_user_group => $tools_install_group,
archive_file => $weblogic_archive_file,
deploy_location => $weblogic_location,
oracle_inventory_location => $inventory_location,
oracle_inventory_user => $oracle_install_user,
oracle_inventory_group => $oracle_install_group,
jdk_location => $jdk_location,
redeploy => $redeploy,
remove => $weblogic_remove,
patch_list => $weblogic_patches_list,
require => Pt_deploy_jdk['jdk'],
}
}
The manifests under pt_setup
will do the heavy work of installing new software. This custom manifest will deploy Java and WebLogic on our servers. If your bootstrap script didn’t create a dpk\archives
folder, the installation will fail. The DPK manifests (and our custom one) will look for the archives before it attempts to install.
Installation
Once your custom manifests are built, go to the puppet\etc\manifests
folder. Run the command
puppet apply .\weblogic.pp --trace --debug
to install WebLogic.
Future Improvements
When I did the test, I tried to follow the Roles and Profiles pattern used by the DPK. It might seem complex for a smaller installation. You could combine all this into one manifest, but then it gets ugly to maintain. When we add more software components, the abstraction between configuration and implementation allows us to re-use Puppet code.
This was a test for myself to see if I could break down some of the abstraction in the DPK and write (or modify) manifests to control more of the process. Plus, we have DPK role that we can use for WebLogic-only deployments 🙂
Note: This was originally posted by Dan Iverson and has been transferred from a previous platform. There may be missing comments, style issues, and possibly broken links. If you have questions or comments, please contact [email protected].