Opinion: For Rails app configuration expecting all conf files in shared/config

[notapatch]

Opinion:

I was expecting all configuration files in shared/config and then sym-link to the appropriate directories ... nginx/sites-available say.

This allows me to go to home/myapp/shared/config to check all my configuration files rather than hopping around the Ubuntu system (I mean really am I supposed to remember /etc/nginx/sites-available :-) ).

[bruno-]

Hi Richard,
I'm with you on this one, and was thinking about it too.
The main reason why the nginx configuration file is copied to sites-available directory is because this plugin has it that way too.

Being primarily a rails developer, I too would like to have nginx config file in my app shared directory.
In fact, if nginx config was moved to apps shared dir, I think that would solve issue #3 you brought up.

The reason I haven't done this so far is the lack of knowledge from the sysadmin standpoint. For example, what if keeping nginx config file in sites-available is a strong convention in sysadmin world (one that overrides our rails developers comfort)? What if there are benefits to that we're not aware of?

So, before taking an action on this (one that I would like to take), I'll first investigate it and answer a question: are there benefits to keeping the nginx config file in sites-available over the application shared dir?
I guess a good starting point is asking for an opinion on nginx forum or irc..

Let me know if you find a resource related to this.

[notapatch]

Agreed, if a sysadmins doesn't see something in sites-available they will be out of their comfort zone.

What about 2 symlinks..

1. shared/config to sites-available
2. sites-available to sites-enabled

That way a sysadmin would be able to follow what was happening as he would have a 'normal' setup of a config file in sites-available and sites-enabled and could remove sites-enabled and have an effect. While programmers could keep everything in one directory.

Obviously a big assed sign saying 'Deployed by Capistrano' to help them get their bearings.

If you think that's an interesting idea we can run it by the other project and see what they think. Basically more people will understand but the process is less robust.

Of course you might not want to try the idea of someone who uninstalls using rm -rf ~/apps/project name :-)

rich

[bruno-]

I opened a question here: kalys/capistrano-nginx-unicorn#21

I see the idea behind 2 symlinks. That seems like a "lot of work".. but we'll see when we learn more about this.

[notapatch]

Thanks Bruno! I will listen with interest.

On Wed, Apr 9, 2014 at 3:01 PM, Bruno Sutic [email protected]:

I opened a question here: kalys/capistrano-nginx-unicorn#21kalys/capistrano-nginx-unicorn#21

I see the idea behind 2 symlinks. That seems like a "lot of work".. but
we'll see when we learn more about this.

Reply to this email directly or view it on GitHubhttps://github.com/bruno-/capistrano-unicorn-nginx/issues/2#issuecomment-39966878
.