Puppet roles and profiles to the max
In this picture, we have drawn a High-Available setup for a WebLogic and Oracle system. Most larger enterprises use a setup like this for their production environment. But it is needlessly costly and resource hungry when you provide this setup for simple, functional tests. Or even worse, provide your developers with this setup. What if we could use the same Puppet code to install and manage the application setup on both this High-Available setup and all the other setups. This blog post shows you how to use Puppet roles and profiles to do just that.
Regular and portable setup
The picture in the intro depicts a HA setup. For a developer, we would like to have a single machine containing all functions. For regular testing, we could use a setup where the database and the WebLogic functions are provided by separate systems. Here is a picture of both of the simpler setups.
Similarities
When we inspect the Puppet code to build this configuration, we see that for a lot of the Puppet code it doesn’t matter if it is a WebLogic cluster or just a single node or even a portable one. Same goes for the database. The Puppet code to manage the schemas, tablespaces and users is very similar on a single node and a RAC node. If we could somehow use these modules on all setups, we’d be ok:
- App Deployment & Settings
- App Schemas & Content
Roles and profiles
Craig Dunn introduced the concept of profiles and roles in his blog article Designing Puppet – Roles and Profiles. When he talks about roles, he says:
In our setup we see the following roles:
- stand-alone database server
- master database server
- database server (in cluster)
- stand-alone WebLogic server
- master WebLogic server
- WebLogic server
- portable
Let’s look into each of these roles.
stand-alone database server
This is a normal database server running on a single node. It runs the Oracle database processes. The Puppet code for this role, makes sure the database settings, tablespaces, users, schemas and content is managed.
master database server
This role describes the master node of a RAC cluster. RAC doesn’t know the concept of a master node, but for Puppet it is beneficial to have one of the RAC nodes be responsible for managing the content and settings of the databases.
database server (in cluster)
As far as Puppet is concerned, this role is just a RAC database node. It doesn’t manage any of the content and other settings. Those are done by the master.
stand-alone WebLogic server
This is a standard WebLogic node. The Puppet definition for the role, manages the whole WebLogic setup including the definition of domains, managed servers, data sources, queues, and deployments.
master WebLogic server
This role is very similar to the standalone WebLogic server, but it adds the management of the WebLogic cluster(s) and manages servers on all nodes of the cluster. Just like on the database, we do all the management of WebLogic configuration on the WebLogic master node.
WebLogic server
This role, just manages the software, patches and directories on the machine. When creating the node, the domain configuration is copied from the master node. After this node is part of the WebLogic cluster, technical there is no difference with the master node. Still we use Puppet just to manage the master node and let WebLogic distribute the changes to the other nodes in the cluster. This allows us to easy scale the number of WebLogic servers.
portable
Last, but certainly not least, is the portable role. This role contains everything. It contains a full running database with schemas and content and a full installed and configured WebLogic server. This role is extremely handy to provide fast and adequate development environments.
What about the profiles?
Craig said in his blog post:
If we look at our setups, we can see the following profiles:
- App Deployment & Settings
- App Schemas & Content
- WebLogic Software on a master
- Oracle Db single on a master
- WebLogic software on a server
- Oracle DB on a server
- base OS and Network
How to fit them together?
In this blog post, we have provided you with the basic information on how to structure the different elements of this setup. In the next blog post, we are going to show you how to fit them together into multiple working setups.