Home / server / Questions / 542732
Accepted
quickshiftin
Asked: 2013-10-01 08:55:13 +0800 CST

Nginx conf.d files via puppet

  • 772

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?

nginx

2 Answers

  1. Best Answer

    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.

    • 2

  2. 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.

    • 0