Binary location change, Config location change, mountable sites-enabled folder

[vovimayhem]

• Binary location change
• Config location change
• Mountable sites-enabled folder

[yosifkit]

This is the fix for #10. I think this is a great change. My minor concern is that the echo lines for the nginx.conf and sites-enabled/default.conf seem to be getting long. Would it be better to just COPY the two of them? It would give us better control over the whole file and let users know what the file is by looking at the git repo.

Should we also add VOLUME /usr/share/nginx/html?

Thoughts?

/cc @tianon

[yosifkit]

One more thought is to just make this VOLUME /etc/nginx

[vovimayhem]

Right now /etc/nginx has some default config files (mime.types, for example) that I think a "regular" user will not be aware of their existence...

[stuartpb]

That doesn't really affect making all of /etc/nginx a volume in the Dockerfile, though. (Plus, for purposes like this image's use in Plushu, we want to override those files anyway.)

[tianon]

I'm not a fan of calling this "sites-enabled" because that's a delta from upstream. Why not just call it "conf.d" instead, since that's what it is?

Also, I think we need to decide whether it would be "more upstream" for us to switch to their packages instead of compiling ourselves, which might also have a bearing on this issue.

[vovimayhem]

@yosifkit

• I hesitated over the COPY/ADD of files before sending the PR... but on second thought, maybe it is desirable to do it.
• Adding VOLUME /usr/share/nginx/html: I see no problem with that, but that will just allow customizing the contents of the default VHost/Virtual site... which I find myself disabling it 100% of the time...
• Adding VOLUME /etc/nginx: There are some not-so-trivial config files in that folder that some users would not be aware of (think mime.types file), and could get unexpected results when mounting volumes (without those files) in that path.

@tianon

• The 'sites-enabled' name also was giving me a funny feeling, but thought it was an established expected behavior... I'd be totally cool with the 'conf.d' name.
• I thought there's a special reason for compiling nginx ourselves, but I'm not sure what it is...

[yosifkit]

I agree with your points. If someone wants to -v mount /etc/nginx they should know what they are doing, the VOLUME would just advertise trouble.

@tianon do we want to change to using packages rather than source?

[tianon]

Yeah, I think we should switch this to use upstream's packages so we can
very easily have both a "stable" and a "mainline" version (especially since
upstream actually recommends that we use the packages).

Also, since this image is used equally well for static websites as it is
for just nginx being a super-slick proxy, I think the HTML location should
not be a volume in this case. We talked about doing that for Wordpress
because Wordpress's source is actually stateful, where static HTML
wouldn't/can't be.

[yankeeinlondon]

I really like the "/nginx/conf.d" suggestion.

BTW, what is stopping this PR from being accepted? Is this imminent?

[yosifkit]

Sorry for the delay in responses here.

Nginx upstream will now be providing and maintaining the images nginxinc/docker-nginx. Which already includes the '/etc/nginx/` directory for configuration as a volume. (docker-library/official-images#197)

So, this repository will be deprecated.