I’m trying to determine where to draw the line between what goes in puppet and what is part of an ‘application’. One place I’m a bit perplexed is nginx conf.d files.
In apache, I’d have these files marked as .htaccess and thus, part of the application. However, in nginx there are no .htaccess files; they must go in the conf.d directory and the server bounced.
Fair enough, but when it comes to packaging the application and deploying server configuration with puppet I find the line between server configuration and application land rather blurry here.
If I put the files in the application package (we’re using RPM), then I have server configuration in the application. However, if I put the files in puppet and the application author wishes to make a change (add another /location, or a rewrite etc..) then I have to update puppet and now the next version of the application depends on a puppet release.
Seems like a chicken and egg problem to me. Where is the most appropriate place to put these conf.d files then, puppet or application RPM?
I think the right answer here is going to be driven by business considerations, not technical ones.
In general, my advice is: If the developers maintain this file as part of the application, then they should package and ship it as part of the application. But they also have to have the responsibility if their changes break production.
If you maintain this file, or if they aren’t responsible if they break production, then you should maintain the file and put it in puppet.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.