2

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?

quickshiftin
  • 2,125
  • 5
  • 27
  • 41

2 Answers2

2

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.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • I see, so not much of a standard practice on this, just comes down to the environment I'm working in? This is one area I'm struggling a bit with Puppet, the divide between system configuration and application, to some extent, it seems arbitrary. – quickshiftin Sep 30 '13 at 17:57
  • 1
    To some extent. Hell, you could stuff the whole app into a filebucket and have Puppet deploy it, but that's not really what it's meant for. Or you could have your devs run the server... either extreme is madness. So you have to live somewhere in the middle. – Michael Hampton Sep 30 '13 at 17:59
0

However, in nginx there are no .htaccess files;

correct

they must go in the conf.d directory and the server bounced.

not correct; they can go wherever you want, you just need to include the files or whole directories like this:

You can include any configuration files for what ever purpose you want. include vhosts/*.conf;

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

quite the opposite is true, because of a different concept: with .htaccess you mix application with server-configuration, while in nginx-land one usually let the application handle requests. nginx is much more commong as reverse-proxy infront of application-server that serve REST-style URLs than as a gateway to stuff like typo3 with a huuuge .htaccess to make seo-friendly urls instead of /index.php?id=23&project=23&page=13&lang=fr

back to your question: what michael said, plus (slightly OT): we use fabric for immediate/interactive changes (puppet runinterval is set to 15 minutes), because we want to have

  1. an deployment-process and active action for such changes, meaning: someone MUST press a button
  2. the possibility to see, detect und immediate repair hickups, e.g when a configtest fails
  3. push config-changes usually onto a standy-server for testing first, and if it works, update live-servers.

but YMMV.

that guy from over there
  • 1,355
  • 10
  • 11
  • It's good to know that the files don't need to go in the conf.d directory, but the server does need to be bounced. Also, I find apache allows a cleaner separation via .htaccess files. The vhosts are the server, the .htaccess is the application. Even though you are configuring apache via .htaccess, it offers a clean way to ship server configuration changes with the application. With nginx, that's really not possible IMO. Obviously nginx is faster, so it's all about tradeoffs in the end. – quickshiftin Sep 30 '13 at 23:01
  • 1
    yes, you need to **RELOAD** the server, thus no connection will be dropped. – that guy from over there Oct 01 '13 at 06:35