Как вы разворачиваете приложение фляги или django, используя jwilder / nginx-proxy? - PullRequest
Новая
       16

Как вы разворачиваете приложение фляги или django, используя jwilder / nginx-proxy?

0 голосов
/ 26 августа 2018

Я планирую переместить некоторые из наших веб-серверов в докер-контейнеры.Образ jwilder / nginx-proxy выглядит интересно и, кажется, делает то, что мы хотим, но как правильно развернуть приложение фляги в контейнере и заставить его работать с прокси-сервером jwilder / nginx-proxy?Чтобы было ясно, колба также будет работать в док-контейнере.

В отдельном, но связанном вопросе, как это сделать для приложения django?

Похоже, что естьпопулярное изображение tiangolo / uwsgi-nginx-flask и аналогичное изображение dockerfiles / django-uwsgi-nginx.В этой настройке, насколько я понимаю, контейнер nginx-proxy будет направлять трафик в контейнер uwsgi-nginx-flask или django-uwsgi-nginx.Это обычный способ сделать это?

Основная мысль, которая у меня возникла, заключалась в том, что при такой установке мы запускаем дополнительные экземпляры nginx - по одному для каждого приложения python / django.Это распространено?Или это возможно / полезно / распространено, чтобы как-то говорить nginx-proxy напрямую с uwsgi в контейнере приложения python?

Я вижу, что образ nginx-proxy имеет опцию VIRTUAL_PROTO=uwsgi, что другие контейнеры могут бытьначалось с.Это то, что можно использовать для повышения эффективности?Или это больше усилий, чем стоит?

Редактировать: Или полезен экземпляр nginx, сопровождающий проект flask / django, поскольку его можно использовать для обслуживания статического контента, без которого вам потребуется настроитьИзображение nginx-proxy с расположением статических файлов каждого проекта?

1 Ответ

0 голосов
/ 26 августа 2018

Лично я предпочитаю, чтобы у Django был один контейнер, NGINX в отдельном контейнере, другие приложения в других контейнерах и т. Д. Для этого я предпочитаю использовать docker-compose . Вы можете проверить мою реализацию об использовании Django + NGINX + PostgreSQL в здесь . (Я не использовал jwilder / nginx-proxy, вместо этого я использовал официальный образ докера NGINX)

Но размещение NGINX и Python-сервера в одном контейнере звучит не так уж плохо. Я использовал легкие альпийские изображения для развертывания Python, например: 

FROM nginx:mainline-alpine

# --- Python Installation ---
RUN apk add --no-cache python3 && \
    python3 -m ensurepip && \
    rm -r /usr/lib/python*/ensurepip && \
    pip3 install --upgrade pip setuptools && \
    if [ ! -e /usr/bin/pip ]; then ln -s pip3 /usr/bin/pip ; fi && \
    if [[ ! -e /usr/bin/python ]]; then ln -sf /usr/bin/python3 /usr/bin/python; fi && \
    rm -r /root/.cache

# --- Work Directory ---
WORKDIR /usr/src/app

# --- Python Setup ---
ADD . .
RUN pip install -r app/requirements.pip

# --- Nginx Setup ---
COPY config/nginx/default.conf /etc/nginx/conf.d/
RUN chmod g+rwx /var/cache/nginx /var/run /var/log/nginx
RUN chgrp -R root /var/cache/nginx
RUN sed -i.bak 's/^user/#user/' /etc/nginx/nginx.conf
RUN addgroup nginx root

# --- Expose and CMD ---
EXPOSE 5000
CMD gunicorn --bind 0.0.0.0:5000 wsgi --chdir /usr/src/app/app & nginx -g "daemon off;"

Хотя это выглядит немного грязно, но работает нормально. Пожалуйста, ознакомьтесь с моей полной реализацией на здесь .

В зависимости от того, как вы хотите развернуть образы докеров, вы можете использовать любой из подходов. Но использование docker compose было бы лучшим решением ИМХО. И в обеих настройках вы можете использовать NGINX для обслуживания статического содержимого (нет необходимости настраивать его для каждого статического файла).

...