Main configuration values
common.yaml contains most of the configuration for Tiller. It contains top-level
default_environment parameters. If you are using the file plugin (which you usually will be) it also typically contains configuration sections for each environment.
It can also take optional blocks of configuration for some plugins (for example, the Consul Plugins). Settings defined here can also be overridden on a per-environment basis.
This is simply what will be executed after the configuration files have been generated. If you omit this (or use the
--no-exec arguments) then no child process will be executed. You should specify the command and arguments as an array, e.g.
exec: [ "/usr/bin/supervisord" , "-n" ]
This means that a shell will not be spawned to run the command, and no shell expansion will take place. This is the preferred form, as it means that signals should propagate properly through to spawned processes. However, you can still use the old style string parameter, e.g.
exec: "/usr/bin/supervisord -n"
This parameter specifies the data source plugins you'll be using to populate the configuration files. This should usually just be set to "file" to start with, although there are a lot of bundled plugins provided. You can also write your own plugins and pull them in. These plugins are provided as a YAML array, for example:
data_sources: [ "file" , "consul" , "environment"]
Or in the long-form:
data_sources: - file - consul - environment
This parameter specifies which plugin will be providing the templates. It uses the same array syntax as
template_sources: [ "file" ]
IMPORTANT NOTE : The order in which you specify plugins is important. Plugins will be loaded in the order they are specified, so in the following example, values from the environment will take precedence over anything specified in
common.yaml from the file plugin, and templates from Consul will take precedence over anything from the filesystem:
data_sources: [ "file" , "environment" ] template_sources: [ "file" , "consul" ]
This parameter sets the default environment to use if one is not specified (either using the -e flag, or via the
environment environment variable). This defaults to 'development'.
For a simple use-case where you're just generating everything from files and then spawning MongoDB with a different replica set name specified in the staging and production environments, you'd have a common.yaml like this:
--- exec: [ "/usr/bin/mongod" , "--config" , "/etc/mongodb.conf" , "--rest" ] data_sources: [ 'file' ] template_sources: [ 'file' ] environments: staging: mongodb.erb: target: /etc/mongodb.conf user: root group: root perms: 0644 config: replSet: 'staging' production: mongodb.erb: target: /etc/mongodb.conf config: replSet: 'production' development: mongodb.erb: target: /etc/mongodb.conf
And a mongodb.erb template that contained:
... ... rest of file snipped ... <% if (replSet) -%> replSet = <%= replSet %> <% end -%>