cookiecutter-django: missing environmental variables nginx container

Hi, I am trying to evaluate cookiecutter-django, so far its a great tool to start a project. everything is going smooth except when I tried to use docker with certbot, i’m having this error.

nginx_1 | 2016/06/15 07:55:36 [emerg] 1#1: invalid port in upstream "___LETSENCRYPT_IP___:___LETSENCRYPT_PORT___" in /etc/nginx/nginx.conf:42

start.sh contains

sed -i "s/___LETSENCRYPT_IP___/$LETSENCRYPT_PORT_80_TCP_ADDR/g" /etc/nginx/nginx.conf
sed -i "s/___LETSENCRYPT_PORT___/$LETSENCRYPT_PORT_80_TCP_PORT/g" /etc/nginx/nginx.conf

I’m not a guru here, but I can see that the script is referencing with environmental variables, but when i tried to inspect the enviromental variables in nginx container, I didn’t see anything related to letsencrypt.

[root@localhost]# docker-compose run nginx bash
Starting tbpcsuite_certbot_1
Starting tbpcsuite_postgres_1
Starting tbpcsuite_redis_1
Starting tbpcsuite_django_1
root@b7d12c245b86:/# set
BASH=/bin/bash
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
BASH_CMDS=()
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="4" [1]="3" [2]="30" [3]="1" [4]="release" [5]="x86_64-pc-linux-gnu")
BASH_VERSION='4.3.30(1)-release'
COLUMNS=197
DIRSTACK=()
EUID=0
GROUPS=()
HISTFILE=/root/.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/root
HOSTNAME=b7d12c245b86
HOSTTYPE=x86_64
IFS=$' \t\n'
LINES=73
MACHTYPE=x86_64-pc-linux-gnu
MAILCHECK=60
MY_DOMAIN_NAME=www.192.168.33.10.xip.io
NGINX_VERSION=1.11.1-1~jessie
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PIPESTATUS=([0]="1")
PPID=0
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
PS2='> '
PS4='+ '
PWD=/
SHELL=/bin/bash
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
SHLVL=1
TERM=xterm
UID=0
_=']'

I’m lost, any guidance I will appreciate.

Thanks,

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 23 (20 by maintainers)

Most upvoted comments

Before we dig deeper into correcting this issue, I just wanted to compliment @mjsisley on the work he’s done on Let's Encrypt and Certbot in Cookiecutter Django. He’s solving a very hard problem, which is ensuring easy-to-use HTTPS for all users done through the abstraction that occurs when generating Cookiecutter templates.

With that, I also want to say that I expected a few bumps along the way, the same we encountered when we were polishing our Celery and Docker setups. These things happen, and it’s perfectly okay. Especially in a framework like Cookiecutter Django which likes to push certain boundaries.

To summarize: Thank you @mjsisley for your hard work on the Certbot stuff. 💃

pydanny on Jun 16, 2016

@jamespacileo You can use the names of the containers instead of the env. vars (see #636 ) - docker’s new networking handles the name resolution.

The problem is nginx isn’t happy if one of the upstreams isn’t up. After we run with the initial nginx.conf and run certbot, we restart with the nginx-secure.conf but certbot is no longer up. Since nginx-secure.conf references certbot (and it needs to in order to have renewals work), nginx can’t switch to the new conf.

I’ve updated the original pull request (#636) with a better workaround that should support renewals. By setting the proxy_pass server as a variable and using the resolver directive, I’m telling nginx to perform the container name -> resolution dynamically. I’m getting the dns server of the container from /etc/resolv.conf (this will point at the docker network dns server) and setting the resolver to it.

Based on: https://trac.nginx.org/nginx/ticket/658 https://tenzer.dk/nginx-with-dynamic-upstreams/ http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

mirskiy on Jul 25, 2016

I think this error may be related to docker’s new networking features. Since the link environmental variables have been deprecated (https://docs.docker.com/compose/link-env-deprecated/), they are no longer replaced. I was able to get running by just using the actual container names in the conf, see #636. Seems it’s already corrected for the django container - APPLICATION_IP has been replaced with django in the nginx confs.

mirskiy on Jun 19, 2016

Here you go:

CMD /start.sh in the Dockerfile
remove the location /.well-known/acme-challenge blocks from nginx-secure.conf
make the changes for nginx.conf and start.sh provided here

aleprovencio on Jul 24, 2016

It also solves for me, but as I mentioned on the PR, this new issue emerged: nginx: [emerg] host not found in upstream "certbot" in /etc/nginx/nginx.conf:42

aleprovencio on Jun 21, 2016