Virtual resources allow us to stage resources to be used by the node they were created on. Expanding on this, exported resources allow a node to create a virtual resource and share it with other nodes in the infrastructure. Exported resources are a useful way to design automated systems that need information from other automated systems. In implementation, you can think of an exported resource as virtualized and announced. The resource is not realized on the system (although it could be), and it is instead shared with the rest of the infrastructure. This allows us to build systems that manage things based on knowing the states of other nodes in the infrastructure.

Declaring an exported resource is done in the same way as a virtual resource, except we use two @ symbols instead of one:

class profile::fillsuptmp 
{
  # Exported Resource. Virtual and Shared
  # Notice that only the @@ is different!
  @@file {
"/tmp/${::fqdn}":
    ensure  => present,
    content => $::ipaddress,
    tag     => ['Fillsuptmp']
  }
}

Although we wouldn't want to use this particular example, we could realize this resource on the local system using file <| |> and receive just the local resource. By adding an additional set of brackets, <<| |>>, our infrastructure would take this file as described by every node in the infrastructure. The following example shows how to retrieve our resources from an exported catalog:

class profile::filltmp {
# This simple declaration will call our file from above and place one from
# each machine on the system. Notice the title containing $::fqdn, so a new
# file in /tmp will be created with the FQDN of each machine known to PuppetDB.
  
  include profile::fillsuptmp

  File <<| tag == 'Fillsuptmp' |>>
}

We'll add this profile to our site.pp outside of a node definition so that it is utilized by all nodes:

# site.pp

include profile::filltmp

When we run the agent, we will see a file being placed in /tmp for each node in the infrastructure.  For each node that checks into the master, all other nodes will also gain a new file:

[root@wordpress vagrant]# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for wordpress
Info: Applying configuration version '1529121275'
Notice: /Stage[main]/Profile::Fillsuptmp/File[/tmp/wordpress]/ensure: defined content as '{md5}c679836c51e9e0e92191c7d2d38f5fe5'
Notice: /Stage[main]/Profile::Filltmp/File[/tmp/pe-puppet-master]/ensure: defined content as '{md5}c679836c51e9e0e92191c7d2d38f5fe5'
Notice: Applied catalog in 0.10 seconds

One thing to take note of with exported resources: Your node that realizes these resources will eventually converge to the intended state of the infrastructure. Until a node reports this resource to the Puppet Master, your node will be unaware of the existence of the node. Let's use a scenario where you have a new node that you've classified with an external resource in the catalog. Until that node checks into the master for the first time, that resource will not populate into PuppetDB. Even after it checks into PuppetDB, the node realizing the resource must also run another puppet agent run. This means that, on a node that has just run Puppet with the default timer of 30 minutes, it may take 30 minutes to report its exported resource to the Puppet Master. Then, your node collecting these resources may take up to another 30 minutes to check in with the master and receive these changes. Exported resources are not immediate, but your infrastructure will eventually converge around the new information provided to PuppetDB.