Exported resources are declared with the @@ operator. You define the resource as you normally would, but prepend the definition with @@. For example, consider the following host resource:

host {'exported':
  host_aliases => 'exported-resources',
  ip    => '1.1.1.1',
}

It can be declared as an exported resource as follows:

@@host {'exported':
  host_aliases => 'exported-resources',
  ip    => '1.1.1.1',
}

Any resource can be declared as an exported resource. The process of realizing exported resources is known as collecting.

Collecting is performed using a special form of the collecting syntax. When we collected virtual resources, we used <||> to collect the resources. For exported resources, we use <<||>>. To collect the previous host resource, we use the following:

Host <<| |>>

To take advantage of exported resources, we need to think about what we are trying to accomplish. We'll start with a simplified example.

It makes sense to have static host entries in /etc/hosts for some nodes, since DNS outages may disrupt the services provided by those nodes. Examples of such services are backups, authentication, and Kerberos. We'll use LDAP (authentication) in this example. In this scenario, we'll apply the ldap::server class to any LDAP server and add a collector for Host entries to our base class (the base class will be a default applied to all nodes). First, declare the exported resource in ldap::server, as shown in the following code snippet:

classldap::server {
  @@host {"ldap-$::hostname":
    host_aliases => ["$::fqdn",'ldap'],
    ip           => "$::ipaddress",
  }
}

This will create an exported entry on any host to which we apply the ldap::server class. We'll apply this class to node2 and then run Puppet to have the resource exported. After running Puppet agent on ldapserver1, we will examine the contents of PuppetDB, as shown in the following screenshot:

The catalog_resources table holds the catalog resource mapping information. Using the resource ID from this table, we can retrieve the contents of the resource from the resource_params table, as shown in the following screenshot:

As we can see, the ldapserver1 host entry has been made available in PuppetDB. The host_aliases and ip information has been stored in PuppetDB.

To use this exported resource, we will need to add a collector to our base class as follows:

class base {
  Host <<| |>>
}

Now, when we run puppet agent on any host in our network (any host that has the base class applied), we will see the following host entry:

[root@client ~]# grepldap /etc/hosts
10.0.2.15  ldap-ldapserver1  ldapserver1.example.comldap

The problem with this example is that every host with ldap::server applied will be sent to every node in the enterprise. To make things worse, any exported host resource will be picked up by our collector. We need a method to be specific when collecting our resources. Puppet provides tags for this purpose.