Many applications require databases to store information between sessions. In many large organizations, it is common to centralize these databases and point applications to them externally. The following example will consist of two profiles: one for the database and one for the application seeking to use the database.

In the following example, the appserver::database profile provides a very simple installation of MySQL. It also retrieves all mysql::db resources tagged ourapp, and realizes them on the central server. The appserver profile accepts a parameter for the password that could be supplied via hiera or encrypted using eyaml. Using this password, it will export a database resource to be collected and realized on the database server. Other configurations could be made to an application on this server to ensure it uses the database provided by this exported resource:

class profile::appserver (
  $db_pass = lookup('dbpass')
) {
  @@mysql::db { "appdb_${fqdn}":
    user     => 'appuser',
    password => $db_pass,
    host     => $::fqdn,
    grant    => ['SELECT', 'UPDATE', 'CREATE'],
    tag      => ourapp,
  }
}

class profile::appserver::database {
  
  class {'::mysql::server':
    root_password => 'suP3rP@ssw0rd!',
  }

  Mysql::Db <<| tag == 'ourapp' |>>
}

We'll go ahead and insert these profiles into the node definition for our appserver and a new node definition for mysql. This configuration will ensure that our appserver has a relevant database on the mysql server, and that its application is forwarded properly through the haproxy. Notice the passing of the password on the appserver node:

#site.pp

include profile::etchosts

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 applied to a previously configured database server, with a freshly exported resource from our appserver, a new database, database user, and set of permissions has been created on the DB Server:

[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 '1529037526'
Notice: /Stage[main]/Profile::Appserver::Database/Mysql::Db[appdb_appserver]/Mysql_database[appdb_appserver]/ensure: created
Notice: /Stage[main]/Profile::Appserver::Database/Mysql::Db[appdb_appserver]/Mysql_user[appuser@appserver]/ensure: created
Notice: /Stage[main]/Profile::Appserver::Database/Mysql::Db[appdb_appserver]/Mysql_grant[appuser@appserver/appdb_appserver.*]/ensure: created
Notice: Applied catalog in 0.34 seconds

One flaw with this system is the up to 30-minute gap between the appserver being launched and the database being realized on the system. In the next chapter, we'll also be discussing application orchestration, which helps solve this problem by linking nodes together and orchestrating the agent runs. If you have time to let the infrastructure converge, this exported resource can work for databases and applications alone.