Ever since the introduction of the create_resources function, Puppet® enabled us to store resource definitions in hiera and create them at run-time. This allowed us to define resources both in hiera data as well as in Puppet® manifests. But when do you put something in hiera and when do you use regular Puppet® code? In this blog post, we are going to give you some guidelines.

Craig Dunn introduced the concept of profiles and roles in his blog article Designing Puppet® – Roles and Profiles. This diagram shows how the role::portable is made up of five different profiles. It also shows the dependencies between the different profiles. In our last post Puppet roles and profiles to the max. We introduced the roles and profiles required for a multifunctional setup. In this blog post, we are discussing how to connect them together to get good working setups. We are going to use the portable role for this.

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.

So now you have used Puppet® to manage your application schema in the database. But you notice that the application also has some settings stored in tables inside of the database. Settings for external services like the URL of a WebService or the UNC of a server you have to connect to. Settings that contain different values in the production environment than in the test or development environment. This situation is a perfect match for Puppet. But how do we get Puppet® to do this? This post will show you how the ora_config module, makes this possible.