Pulling Strings With Puppet - James Turnbull [27]
Using virtual resources gets around this problem. A virtual resource is only configured once but can be instantiated multiple times in our configuration.
We can identify virtual resources by the @ symbol prefixed to the resource type like so:
Puppet implements a virtual resource using a feature known as realization. Realization offers two methods for marking a virtual resource so that it is implemented. The first is called a collection, and the second uses a function called realize.
Realizing with a Collection
The collection method uses simple selection syntax to select the resources to be realized like so:
The type of the resource being realized is specified and capitalized. The selection syntax itself is encapsulated in angle brackets and vertical bars. We then specify the selection syntax; here we're realizing a user resource with a title equal to james. We can also specify nonequality like so:
The previous line would realize all users EXCEPT those with a title equal to james. Selection syntax can also make use of parentheses as well as and/or statements like so:
The last line would realize all group resources with a title of admin or a title of mainframe.
You can also realize all resources of a type like so:
The last line would realize all User type virtual resources.
Realizing with the realize Function
In addition to the collection method, Puppet also has a simple function, realize, for realizing virtual resources. The realize function uses the resource reference, for example, User[james], to refer to a virtual resource that is to be realized, as you can see in Listing 320.
Listing 3-20. Realizing Resources
Here with the realize function we've realized the user resource james and the group resources admin and mainframe. You can see we've specified multiple resources to be realized by separating them with commas and enclosing them in brackets.
Note - There is another variety of virtual resource called exported resources. Exported resources are virtual resources but are also exported to other hosts on your network. Exported resources are identified by the resource type prefixed by two @@ symbols rather than one. Exported resources are still experimental at this stage, so I am not going to address them, but you can read about them at http://www.reductivelabs.com/trac/puppet/wiki/VirtualResources.
Facts
Through this chapter, I've mentioned facts and Facter. Facter and Puppet are closely tied together. Puppet allows you to define and specify configuration to be applied to your nodes. Facter allows to you add information from your nodes to your Puppet configurations; for example, knowing the operating system of the node being configured allows you to customize a configuration resource for that platform (we used Facter in this manner in Listing 3-13 to select the appropriate name for a service depending on the operating system on the node).
Facts are available as variables defined in the top-level scope of your manifests. As we've seen earlier in this chapter, the value of the fqdn fact would be available as variable $fgdn. You can see the available facts about a particular system by executing the facter binary on the command line. A full list of facts and their values will be returned. This list will only contain the variables able to be returned on that particular platform. In Table 3-1, I've listed some of the facts commonly returned on platforms.
(Continued)
Tip - On the Puppet master server, you also have access to other facts. The servername and serverip facts are the most useful, and these return the fully qualified domain name and IP address of the server, respectively.
Facter can also return environmental variables as facts. Facter assumes any environmental