1

I have created a simple website using cookiecutter-django (using the latest master cloned today). Running the docker-compose setup locally works. Now I would like to deploy the site on digital ocean. To do this, I run the following commands:

$ docker-machine create -d digitalocean --digitalocean-access-token=secret instancename

$ eval "$(docker-machine env instancename)"

$ sudo docker-compose -f production.yml build

$ sudo docker-compose -f production.yml up

In the cookiecutter-django documentation I read

If you are not using a subdomain of the domain name set in the project, then remember to put your staging/production IP address in the DJANGO_ALLOWED_HOSTS environment variable (see Settings) before you deploy your website. Failure to do this will mean you will not have access to your website through the HTTP protocol.

Therefore, in the file .envs/.production/.django I changed the line with DJANGO_ALLOWED_HOSTS from

DJANGO_ALLOWED_HOSTS=.example.com (instead of example.com I use my actual domain)

to

DJANGO_ALLOWED_HOSTS=XXX.XXX.XXX.XX (with XXX.XXX.XXX.XX being the IP of my digital ocean droplet; I also tried DJANGO_ALLOWED_HOSTS=.example.com and DJANGO_ALLOWED_HOSTS=.example.com,XXX.XXX.XXX.XX with the same outcome)

In addition, I logged in to where I registered the domain and made sure to point the A-Record to the IP of my digital ocean droplet.

With this setup the deployment does not work. I get the following error message:

traefik_1 | time="2019-03-29T21:32:20Z" level=error msg="Unable to obtain ACME certificate for domains \"example.com\" detected thanks to rule \"Host:example.com\" : unable to generate a certificate for the domains [example.com]: acme: Error -> One or more domains had a problem:\n[example.com] acme: error: 400 :: urn:ietf:params:acme:error:connection :: Fetching http://example.com/.well-known/acme-challenge/example-key-here: Connection refused, url: \n"

Unfortunately, I was not able to find a solution for this problem. Any help is greatly appreciated!

Update

When I run netstat -antp on the server as suggested in the comments I get the following output (IPs replaced with placeholders):

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1590/sshd       
tcp        0      0 XXX.XXX.XXX.XX:22       YYY.YY.Y.YYY:48923      SYN_RECV    -               
tcp        0    332 XXX.XXX.XXX.XX:22       ZZ.ZZZ.ZZ.ZZZ:49726     ESTABLISHED 16959/0         
tcp        0      1 XXX.XXX.XXX.XX:22       YYY.YY.Y.YYY:17195      FIN_WAIT1   -               
tcp        0      0 XXX.XXX.XXX.XX:22       YYY.YY.Y.YYY:57909      ESTABLISHED 16958/sshd: [accept
tcp6       0      0 :::2376                 :::*                    LISTEN      5120/dockerd    
tcp6       0      0 :::22                   :::*                    LISTEN      1590/sshd

When I run $ sudo docker-compose -f production.yml up before, netstat -antp returns this:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1590/sshd       
tcp        0    332 XXX.XXX.XXX.XX:22       ZZ.ZZZ.ZZ.ZZZ:49726     ESTABLISHED 16959/0         
tcp        0      0 XXX.XXX.XXX.XX:22       AA.AAA.AAA.A:50098      ESTABLISHED 17046/sshd: [accept
tcp        0      0 XXX.XXX.XXX.XX:22       YYY.YY.Y.YYY:55652      SYN_RECV    -               
tcp        0      0 XXX.XXX.XXX.XX:22       YYY.YY.Y.YYY:16750      SYN_RECV    -               
tcp        0      0 XXX.XXX.XXX.XX:22       YYY.YY.Y.YYY:31541      SYN_RECV    -               
tcp        0      1 XXX.XXX.XXX.XX:22       YYY.YY.Y.YYY:57909      FIN_WAIT1   -               
tcp6       0      0 :::2376                 :::*                    LISTEN      5120/dockerd    
tcp6       0      0 :::22                   :::*                    LISTEN      1590/sshd
marcu1000s
  • 177
  • 1
  • 8
  • Is your Droplet listening on port 80 and it is delegated to the container? – Vignesh SP Mar 29 '19 at 23:38
  • I must admit that actually I am not sure. I used the standard settings for the droplet and for django-cookiecutter. So I would assume that port 80 should be open and that the port mapping in the docker-compose setup should be correct. To make sure, I tried to run `sudo ufw disable` on the droplet and also tried to flush the ip-tables as described in https://askubuntu.com/questions/676434/port-80-connection-refused . Not sure if there is a way to verify that the droplet is listening on port 80? – marcu1000s Mar 30 '19 at 06:57
  • Try `netstat -antp` and see if the droplet is listening to port 80. – Vignesh SP Mar 30 '19 at 09:00
  • Thank you for your help. I updated the question to show the output of `netstat -antp` – marcu1000s Mar 30 '19 at 11:17
  • Also, try telnet your server on port 80, if the connection fails you need to open the port. `telnet ip.ip.ip.ip 80` – Vignesh SP Apr 01 '19 at 08:10

1 Answers1

2

In my experience, the Droplets are configured as needed by cookiecutter-django, the ports are open properly, so unless you closed them, you shouldn't have to do anything.

Usually, when this error happens, it's due to DNS configuration issue. Basically Let's Encrypt was not able to reach your server using the domain example.com. Unfortunately, you're not giving us the actual domain you've used, so I'll try to guess.

You said you've configured a A record to point to your droplet, which is what you should do. However, this config needs to be propagated on most of the name servers, which may take time. It might be propagated for you, but if the name server used by Let's Encrypt isn't, your TLS certificate will fail.

You can check how well it's propagated using an online tool which checks multiple name servers at once, like https://dnschecker.org/.

From your machine, you can do so using dig (for people interested, I recommend this video):

# Using your default name server
dig example.com

# Using 1.1.1.1 as name server
dig @1.1.1.1 example.com

Hope that helps.

Bruno A.
  • 1,765
  • 16
  • 17
  • Thank you very much for your help. It seemed to me that the config was propagated correctly. Unfortunately, it still did not work. I must admit that I gave up on this and in the end got it to work using Heroku. Still, I'll look into this because it would still be interesting and useful to get this to work. – marcu1000s Apr 06 '19 at 11:16