I'm writing a puppet module for an inhouse application that needs configuration information to access several services: internal APIs, AMQP services, MongoDB database. It accepts a configuration file which specifies the various parameters on setting it up. S
The application is deployed as a Debian package delivered from an internal APT repository. The package does not supply a default configuration file. There is a reliance on Puppet for deployment.
**Question: What is a good way to supply configuration data for this specific use-case (in-house application, in-house module that will not be published on puppetforge) while still abiding by [good practices of separating Puppet code & data](https://puppet.com/blog/problem-separating-data-from-puppet-code)?**
To help understand where I'm coming from, here are the ideas I have already thought of:
(1) Break the configuration down into several granular parameters, then use Hiera to supply each individual parameter. These parameters would then be supplied into a template which constructs the configuration file.
(2) Supply the configuration data as a string parameter (as shown in the below sketch of the module).
(3) Supply the configuration data as a fileserver supplied (puppet://) file.
I find (1) particularly annoying since Puppet now has to know the schema of the configuration file and it would be prudent to also do parameter validation. This means additional Puppet DSL code which I would very much like to avoid.
I have an affinity for (2) but it seems like a very lazy approach. The nice thing about it is, that I can supply the configuration file data directly in Hiera in YAML. But maybe this is not a great idea since I will be bloating Hiera and basically using it as a file-server.
I think (3) makes the most sense, except I don't want to put configuration files in the module directory, because this will again mix code & data. Is it possible to serve the files from the directory environment and instead supply the 'puppet:///' url as a parameter. Even better if we can mix (2) and (3) so that you can supply either a string or URL to plop the data in.
----------
Here is a sketch of the puppet module for reference:
class application(
$config_pathname = "/etc/application/config.toml",
$config_data = "",
)
{
package{'application':}
file{$config_pathname:
content => $config_data,
require => Package['application'],
}
supervisrod::program {'application':
command => "/path/to/app ${config_pathname}",
require => Package['application'],
refresh => File[$config_pathname],
}
}
----------
Example configuration file:
[services_api]
baseurl = "http://services/api"
hmac_id = ""
hmac_provider = ""
hmac_secret = ""
[job_queue]
amqp_uri = "amqp://user:pass@127.0.0.1:5672/jobs"
queue = "jobs"
[finished_queue]
amqp_uri = "amqp://user:pass@127.0.0.1:5672/jobs"
queue = "finished"
exchange = "jobs"
exchange_type = "x-modulus-hash"
route_key = "finished.#"
[mongodb]
hostname = "127.0.0.1"
username = ""
password = ""
ssl = false
db_name_auth = ""
db_name = "jobs"
collection = "job_transcripts"
↧