To do this, I would do something like this:
site.pp:
import "resources/*.pp"
Then I would have a resource file named lifters.pp:
Then in my lifter class, I just do:
Lifter<||>
This works, but as you can imagine it gets ugly. What would be nicer is to be able to manage these in an external nodes classifer such as puppet-dashboard. Luckily with puppet 2.6, we can. We're going to make use of puppet's new pure ruby manifests. The class is going to take all the variables in puppet, including ones created by external nodes, find ones that are both hashes and have a key called :type, and turn those in to resources.
First we need to make a module called externalresources. In the manifests directory, we're going to create a init.rb file instead of a init.pp file. It's important that the init.pp file does not exist. In the init.rb file, we're going to put the following code:
In your site.pp file add this line:
include externalresources
Now we can define parameters in puppet-dashboard and have their values be hashes that look almost like puppet resources. The only difference is we're going to use symbols and we have to add a parameter called :type. Let's create a file resource.
In puppet-dashboard, create a parameter on a host you manage with the dashboard. Name the parameter the title of the file resource. For our example, /tmp/test. For the value, we'll create a hash that looks like this:
{ :type => 'file', :content => "My file's content", :ensure => 'present' }
Now when we run puppet on that host, the file /tmp/test will be created with the content My file's content. For extra fun, we can add the parameter :virtual => 'true' and externalresources will make it a virtual resource that can be realized in other classes.
2 comments:
Hey, thanks for the write up.
When you do this, will modules that extend this be able to get at the variables? What I want to do is create a bunch of erb templates that get 'filled in' during the creation of the manifest. If my understanding of the puppet lifecycle is correct, I think I can use your technique to access data that will be visible to the templates. Is that correct?
This would be a good way to set up a dev/test/prod puppet master that was essentially data driven for configuration files. If I'm completely on the wrong track, let me know.
I apologize, but I'm not following you. What this technique would allow you to do is create a file resource, for example, in puppet-dashboard and have puppet add it to the catalog once you include this class. This way you make changes to the file resource in the GUI without having to modify any puppet code. The template would have to be stored in another parameter and just used as a variable. For example
Parameter 1: '/tmp/foo'
value: { :type => 'file', :content => inline_template( foo_template) }
Parameter 2: 'foo_template'
value: "<%= some value %>"
So I'm not sure this is what you're looking for.
Post a Comment