Предоставление статических файлов через Nginx с прокси HTTPS для gunicorn django в docker-compose - PullRequest
Новая
       16

Предоставление статических файлов через Nginx с прокси HTTPS для gunicorn django в docker-compose

1 голос
/ 10 мая 2019

Я развертываю свое веб-приложение Django / Nginx / Gunicorn в EC2-экземпляре с помощью docker-compose. Экземпляр EC2 имеет статический IP-адрес, на который указывает mywebapp.com / www.mywebapp.com, и я завершил проверку certbot (сайт работает через порт 80 по HTTP), но теперь пытаюсь начать работу по SSL.

Прямо сейчас HTTP (включая загрузку статических файлов) работает для меня, а HTTPS динамический контент (из Django) работает, но статические файлы - нет. Я думаю, что моя конфигурация nginx шаткая.

Я попытался скопировать блок location /static/ в контекст сервера SSL в файле conf nginx, но это привело к тому, что SSL вообще перестал работать, а не только статические файлы через SSL.

Вот последний docker-compose.yml: 

services:
  certbot:
    entrypoint: /bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h &
      wait $${!}; done;'
    image: certbot/certbot
    volumes:
      - /home/ec2-user/certbot/conf:/etc/letsencrypt:rw
      - /home/ec2-user/certbot/www:/var/www/certbot:rw
  nginx:
    command: /bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done
      & nginx -g "daemon off;"'
    depends_on:
      - web
    image: xxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/xxxxxxxx:latest
    ports:
      - 80:80/tcp
      - 443:443/tcp
    volumes:
      - /home/ec2-user/certbot/conf:/etc/letsencrypt:rw
      - static_volume:/usr/src/app/public:rw
      - /home/ec2-user/certbot/www:/var/www/certbot:rw
  web:
    entrypoint: gunicorn mywebapp.wsgi:application --bind 0.0.0.0:7000"
    image: xxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/xxxxxxxx:latest
    volumes:
      - static_volume:/usr/src/app/public:rw
version: '3.0'
volumes:
  static_volume: {}

nginx.prod.conf: 

upstream mywebapp {
    # web is the name of the service in the docker-compose.yml
    # 7000 is the port that gunicorn listens on
    server web:7000;
}

server {
    listen 80;
    server_name mywebapp;
    location / {
        proxy_pass       http://mywebapp;
        proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header Host               $host;
        proxy_redirect   off;
    }
    location /static/ {
        alias /usr/src/app/public/;
    }
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
}

server {
    # https://github.com/wmnnd/nginx-certbot/blob/master/data/nginx/app.conf
    listen 443    ssl;
    server_name   mywebapp;
    server_tokens off;

    location / {
        proxy_pass          http://mywebapp;
        proxy_set_header    Host                $http_host;
        proxy_set_header    X-Real-IP           $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    }

    # generated with help of certbot
    ssl_certificate     /etc/letsencrypt/live/mywebapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mywebapp.com/privkey.pem;
    include             /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam         /etc/letsencrypt/ssl-dhparams.pem;
}

и, наконец, Dockerfile службы nginx: 

FROM nginx:1.15.12-alpine

RUN rm /etc/nginx/conf.d/default.conf
COPY ./nginx.prod.conf /etc/nginx/conf.d

Я просто строю, нажимаю ECR на локальной машине, затем docker-compose pull и запускаю с docker-compose up -d на экземпляре EC2.

Я вижу ошибку в docker-compose logs: 

nginx_1    | 2019/05/09 02:30:34 [error] 8#8: *1 connect() failed (111: Connection refused) while connecting to upstream, client: xx.xx.xx.xx, server: mywebapp, request: "GET / HTTP/1.1", upstream: "http://192.168.111.3:7000/", host: "ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com"

И я не уверен, что происходит не так. Я пытаюсь получить как динамический контент (gunicorn), так и статический контент (из: / usr / src / app / public), правильно обслуживаемый по HTTPS с использованием сертификатов, которые я сгенерировал и проверил.

Кто-нибудь знает, что я могу делать не так?

1 Ответ

1 голос
/ 14 мая 2019

Проверьте файл конфигурации с помощью nginx -T - вы видите правильную конфигурацию?Ваш процесс сборки использует правильный conf?

Полезно просто отладить это на удаленной машине - docker-compose exec nginx sh, чтобы войти внутрь и настроить оттуда conf и nginx -s reload.Это ускорит ваши итерационные циклы при отладке проблемы SSL.

...