We'll be building a file called /tmp/hammer.conf that is comprised of a header section and a variable number of sections provided by exported resources. This class was designed to be used on all machines in an infrastructure, but could easily be turned into a single server configuration file by splitting the exported resource into a separate profile from the concat resource and the header concat::fragment.

In the following example, we're building a manifest that builds hammer.conf. The concat resource gives each fragment a location to build on. The hammer time concat::fragment is used to manage the header, as noted by order 01 in the parameters. Each machine will export a concat fragment detailing an FQDN, IP address, operating system, and version as a line in the file in order to simulate a global configuration file or inventory file. Finally, each machine will realize all of these exported fragments using the resource collector for concat fragments:

class files::hammer {

  $osname = fact('os.name')
  $osrelease = fact('os.release')

  concat {'/tmp/hammer.conf':
    ensure => present,
  }

  concat::fragment {'Hammer Time':
    target => '/tmp/hammer.conf',
    content => "This file is managed by Puppet.It will be overwritten",
    order => '01',
  }

  @@concat::fragment {"${::fqdn}-hammer":
    target => '/tmp/hammer.conf',
    content => "${::fqdn} - ${::ipaddress} - ${osname} ${osrelease}",
    order => '02',
    tag => 'hammer',
  }

  Concat::Fragment <<| tag == 'hammer' |>>

}

We'll add files::hammer outside of any node definitions so that this inventory file is created on all of the machines in our infrastructure:

include profile::etchosts
include files::hammer

node 'haproxy' {
  include profile::loadbalancer
}

node 'appserver' {
  include profile::balancermember
  class {'profile::appserver': db_pass => 'suP3rP@ssw0rd!' }
}

node 'mysql' {
  include profile::appserver::database
}

# Provided so nodes don't fail to classify anything
node default { }

When this is run on our mysql node as the final node in the infrastructure, /tmp/hammer.conf is created and contains Facter facts provided by each node in the infrastructure:

root@mysql 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 mysql
Info: Applying configuration version '1529040374'
Notice: /Stage[main]/Files::Hammer/Concat[/tmp/hammer.conf]/File[/tmp/hammer.conf]/ensure: defined content as '{md5}f3f0d7ff5de10058846333e97950a7b9'
Notice: Applied catalog in 0.33 seconds

# /tmp/hammer.conf
This file is managed by Puppet. It will be overwritten
haproxy - 10.0.2.15 - CentOS 7
mysql - 10.0.2.15 - CentOS 7
pe-puppet-master - 10.0.2.15 - CentOS 7
appserver - 10.0.2.15 - CentOS 7

Most configuration files should be built this way, and be holistically managed by Puppet. In a case where the entirety of a file is not managed, we can use file_line provided by stdlib in its place.