directories soft links (ln -s) question
Let's say I have a web server (Nginx) that looks up files in a certain directory and serves them to users. For example my www doc root is site/ :
/home/me/www/site/
index.html
blah.css
Does that make sense if "site/" actually is a soft link to, say, "sitev1/" like that:
/home/me/www/site -> /some/where/else/sitev1
/some/where/else/sitev1/
index.html
blah.css
That way I only have to change the target pointed by "site" when I want to put sitev1 or sitev2 in production for example.
I tested this configuration, it is working great. But are there any drawbacks or unwanted side effects ? (sorry, I'm new to this)
Thank you
3 Replies
@xado:
I tested this configuration, it is working great. But are there any drawbacks or unwanted side effects ? (sorry, I'm new to this)
Backup tools know to look for symlinks and treat them specially, but nginx likely just opens the file and the kernel does the rest (quite transparently). That transparency allows the kernel to efficiently cache the link translation and Make Things Happen, all with nginx completely oblivious.
In short, the presence of a symlink shouldn't be a bother under reasonable load. If you had millions of symlinks, maybe…
As for backup tools, that depends on the options you use. For example, if you use rsync to copy your stuff to another location, you'll need to set either the -l option or the (more popular) -a option in order for rsync to take care of symlinks automatically.
I think I'll give that symlink based layout a chance. I understand it's pretty much a standard on linux (shared libs in /usr/lib for example) but I was not sure in a webserver context.
As for backup tools, I don't plan to use them because a Git repository is in charge of the site materials. My idea is to export (git archive) interesting branches when they are finalized (sitev1, sitev2..). I then just update the symlink. I would not have to edit nginx.conf and restart the server. Also, if sitev2 is horribly broken, I can quickly switch back to sitev1.