Environment Specific Configuration Management

Derek Stainer

unread,

Jun 17, 2013, 12:15:11 PM6/17/13

to dropwiz...@googlegroups.com

I'm curious how folks manage configuration files, specifically, what tools/processes do you guys use to do two things:

Propagate new properties across environments
Manage environment specific properties, i.e. database urls, usernames and passwords

Thanks

Derek

Justin Rudd

unread,

Jun 17, 2013, 1:24:15 PM6/17/13

to dropwiz...@googlegroups.com

We started off with separate YAML files per environment (production and US, production and UK, production and JP, dev and US, etc.), but that got old really quick. So I built a little code around Typesafe Config (https://github.com/typesafehub/config). It is kind of a hack, but since it only happens at start up time, I'm OK with it.

Basically I write all my configuration using HOCON (https://github.com/typesafehub/config/blob/master/HOCON.md). I then pull it through the following code...

        final Config defaults = getDefaults(allConfig, domain, realm);
        final Config domainAndRealmConfig = getDomainAndRealmConfig(allConfig, domain, realm);
        final Config domainConfig = getDomainConfig(allConfig, domain, realm);
        final Config realmConfig = getRealmConfig(allConfig, realm);

        return combine(defaults, domainAndRealmConfig, domainConfig, realmConfig);

Combine has the following precedence (which makes sense for me)...

domainAndRealm -> domainOnly -> realmOnly -> defaults

Then once they are combined, I then use "Config.resolve" to do my substitutions (it's documented in the HOCON file). You can add as many levels as you need, but just a domain and realm cover my needs.

Here is where the hack comes in, Typesafe Config can serialize its representation as JSON. So I convert it to a Jackson JsonNode and then using the YAMLFactory, write it out as YAML that get's parsed by Dropwizard.

Using Typesafe Config, I get includes, substitutions, etc. So I can have all my DB connections for an environment in one file. That file gets included in all my services. So when a URL changes, I change it one place.

Derek

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Coda Hale

unread,

Jun 17, 2013, 2:00:12 PM6/17/13

to dropwiz...@googlegroups.com

A configuration management tool like Chef, Puppet, or cfengine will be your best bet here.

On Mon, Jun 17, 2013 at 9:15 AM, Derek Stainer <derek....@gmail.com> wrote:

Derek

--

You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Coda Hale
http://codahale.com

Graham O'Regan

unread,

Jun 17, 2013, 4:15:53 PM6/17/13

to dropwiz...@googlegroups.com, dropwiz...@googlegroups.com

If you aren't running puppet/chef already then you may find ansible a more palatable option. We've ported our configuration files to it's jinja templates and it only took a couple of hours to automate

Graham O'Regan

unread,

Jun 20, 2013, 9:03:15 AM6/20/13

to dropwiz...@googlegroups.com

I had a think about this the other day and came up with another possible option if you aren't running on a managed platform. Using Maven for the build you could use its profile support to modify the yml file as part of your build. For example, if you add this to your pom.xml;

<build>

...

<directory>src/main/resources</directory>

</includes>

</resource>

</resources>

...

</build>

And then parameterise your app.yml (or whatever you call it) expressions;

database:

driverClass: com.mysql.jdbc.Driver

user: ${database.user}

password: ${database.password}

url: jdbc:mysql://${database.hostname}/${database.name}

Then you can set these properties in your pom.xml;

<database.user>username</database.user>

<database.password>password</database.password>

<database.hostname>localhost</database.hostname>

<database.name>test</database.name>

</properties>

and then override the settings using a profile;

<database.user>test_username</database.user>

<database.password>test_password</database.password>

<database.hostname>test.mydomain.com</database.hostname>

<database.name>test</database.name>

</properties>

</profile>

...

If you build without specifying a profile then the default settings will be used and the app.yml will be filtered and copied to target/classes/app.yml. If you specify a profile then it will use those settings instead, just run with "mvn -P test install" for the example above.

HTH,

Graham

Konyu Godwin

unread,

Jun 9, 2024, 11:42:55 AMJun 9

to dropwizard-user

Konyu Godwin

unread,

Jun 9, 2024, 11:44:13 AMJun 9

to dropwizard-user

Konyu Godwin

unread,

Jun 9, 2024, 11:45:32 AMJun 9

to dropwizard-user

On Thursday, June 20, 2013 at 2:03:15 PM UTC+1 graham...@gmail.com wrote:

Reply all

Reply to author

Forward