Cookiecutter-django: Adding nginx-proxy

[mjsisley]

nginx-proxy offers at least the following:

• simple nginx load-balancing
• simple zero downtime deployments
• a letsencrypt companion using simp.le, that handles letsencrypt better than what is currently used in this project.
• multiple sites on one IP address.

The first three could be added out of the box, and I could add docs on how to modify the file structure to support the fourth.

Would it be best as an option or could nginx-proxy be in docker-compose by default? Is this beyond the scope of the project?

I can put together a PR if it is wanted.

[audreyfeldroy]

👍 on having nginx-proxy in docker-compose by default. This is meant to be an "ultimate" project template rather than a minimal one, so it's certainly within scope.

And a PR would be great.

[mjsisley]

Great! I'll work on this then. Going to do it in two stages.

1. I'll change the letsencrypt config first to depend on nginx-proxy, and only include it as part of the letsencrypt option. I'l keep everything in docker-compose.yml for this one.
2. The zero downtime deployments require moving postgres and redis to be external services (and linked with external links) relative to nginx, django, celery (I believe). My current personal approach (moving these services to a docker-compose.yml file in a parent directory) doesn't fit the project structure well, but the services can probably be started in a separate docker-compose file instead.

[jayfk]

One thing I'd like to discuss is that nginx-proxy requires to mount the docker socket at least in read-mode. There's no way around that.

This gives the container the ability to observe everything that's happening on the system docker wise, when mounted with r/w it's essentially root.

This might be a bit confusing for people using cookiecutter-django with docker for the first time, since they probably don't have the knowledge what security implications this has.

If it's okay for you, I'd like to put this on hold until consensus is reached.

[mjsisley]

@jayfk What do you use in place of nginx-proxy for load balancing/ multiple sites on one IP/ zero-downtime deployment?

As it shouldn't take too long, I'll put together a PR for the first step (shouldn't be too hard to pull out of what I am using) subject to your review @jayfk. I'll hold off on the second step until consensus is reached on the first step.

Also, if there isn't a good alternative, we could potentially make nginx-proxy an option with a disclaimer for the security implications? Is there anyway to mitigate the security implications?

[pydanny]

@jayfk I'm going to assume that your concerns are summarized in https://raesene.github.io/blog/2016/03/06/The-Dangers-Of-Docker.sock/ and https://www.lvh.io/posts/dont-expose-the-docker-socket-not-even-to-a-container.html. Is that correct?

The counter argument is posted at https://github.com/jwilder/nginx-proxy/issues/242/#issuecomment-142928465. My understanding of it is that the concern is with read-write access, but nginx-proxy is read-only.

As this is a security issue, it behooves us to ask a security professional to weigh in on the subject.

@lvh, could you weigh in on this issue?

[jayfk]

@pydanny That's correct. But even in read-only mode you'll be able to observe everything the docker deamon is doing on the host machine.

I just want to make sure we find the correct balance between security/usability here.

Besides that, I had a couple of conversations in private with @mjsisley, maybe we can consolidate this here.

[lvh]

:ro: doesn't change anything. POC: https://asciinema.org/a/5optugqcp2lflps7r47dr7ids

[lvh]

I'm not going to make that call; but I'll happily document the material facts required to make it :)

[mjsisley]

This should be above... "So the consensus is that the security issues posed by the usage of docker.sock make using nginx-proxy unwise (at least within this project where it may be used without understanding the security implications)?

I can close this issue if this is the case."

Thanks @lvh. No desire to rush the decision... just wondering if that decision has been made because it seems there is now an issue with the current implementation for automated Let's Encrypt usage in this project (which I added).

If nginx-proxy is okay to depend on, I can swap out the Let's Encrypt implementation to use it now. If nginx-proxy isn't alright to depend on (and it seems like it isn't for valid reasons), then I can close this issue.

[mjsisley]

@lvh, does using the docker-gen container separately protect against the read only issue as suggested by @md5 (and supported by @jwilder) in jwilder/nginx-proxy#242 and relevant piece included below:

"Since the socket is already being used to do bidirectional HTTP communication with the deamon, all the threats listed in that article apply to jwilder/nginx-proxy. However, the exploit would have to be a network accessible exploit in Nginx in order to gain access to the socket.

If you're particularly concerned about this threat in terms of using the nginx-proxy image, then you can run a separate docker-gen container that is not exposed to the network as described in the docs."

[jwilder]

In the separate container option for nginx-proxy, an nginx and docker-gen container are run separately sharing a volume. nginx is exposed to the network while docker-gen is not. docker-gen has access to the docker socket and notifies nginx via a signal after the template is regenerated.

[jayfk]

Separating the containers is a bit problematic for the Cookiecutter Django use case, because the nginx container has to be a named container.

If someone wants to run two projects on the same server, the config has to be ripped apart to support that.

[mjsisley]

I agree with @jayfk. The main benefit of nginx-proxy is that you can have multiple sites under one IP address with Docker easily.

Putting it into the project by default just for Let's Encrypt wouldn't make a ton of sense, as those who want to use the full feature set of nginx-proxy would then have to tear apart the config (as you said @jayfk).

[mjsisley]

If this is going to be added, then I think it may make more sense as a separate cookiecutter that gives an option to cookiecutter-django projects (and really any cookiecutter project that uses docker) to be reconfigured to fit within an umbrella multi-project structure.

[matthuisman]

i would also be interested in this.
@mjsisley Did you manage to make a PR so we could at least see how it's done?
I was looking at your
https://github.com/mjsisley/docker-letsencrypt-nginx-proxy-companion-examples

It helped me understand a bit more on how-to use the nginx-proxy with Django.

I originally thought about doing NGINX-proxy -> NGINX-> Django but seemed odd having it pass through two NGINX containers?

But, I quite liked it as I can then make changes to the "inner" NGINX container and do zero downtime deploying the change.

The other way would be try to modify the NGINX-proxy with the specific configs for each site.
But, I guess then you would need to restart the proxy container every time a config changed (casuing down time)?