CloudFoun dry: Как использовать несколько сборочных пакетов? (NGINX + Джанго / Гуникорн) - PullRequest
0 голосов
/ 07 марта 2020

У меня есть Django / Gunicorn + whitenoise (для хранения файлов * stati c), работающий как одно приложение в Cloud Foun dry с использованием следующего файла manifest.yml:

---
applications:
- name: mydjango
  instances: 1
  command: src/tvpv_portal/bin/start_gunicorn_django.sh
  memory: 2048M
  disk_quota: 1024M
  buildpacks:
    - https://github.com/cloudfoundry/python-buildpack.git
  stack: cflinuxfs3
  env:
    DJANGO_MODE: Production

Для обучения / Для экспериментов я бы хотел удалить белый шум и настроить Nginx, используя пакет nginx_buildpack для работы с Django / Gunicorn. Однако я не уверен, как использовать несколько пакетов в одном приложении. Я создал nginx.conf, mime.types и buildpack.yml в каталоге моего проекта, следуя указаниям на https://docs.cloudfoundry.org/buildpacks/nginx/index.html.

nginx .conf

daemon off;

error_log /home/vcap/app/nginx-error.log;
events { worker_connections 1024; }

http {
    log_format cloudfoundry '$http_x_forwarded_for - $http_referer - [$time_local] "$request" $status $body_bytes_sent';
    access_log /home/vcap/app/nginx-access.log cloudfoundry;

    default_type application/octet-stream;
    include mime.types;

    sendfile on;
    gzip on;

    tcp_nopush on;
    keepalive_timeout 30;
    port_in_redirect off; # Ensure that redirects don't include the internal container PORT - 8080

    server {
        listen {{port}};
        server_name localhost;

        # Serve static files.
        location /static/ {
            alias /home/vcap/app/src/tvpv_portal/static/;
        }

        # Serve media files.
        location /media/ {
            alias /home/vcap/app/src/tvpv_portal/media/;
        }

        # Reverse proxy to forward to main app.
        location / {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_pass http://127.0.0.1:8000;
        }
    }
}

Я пытался сделать cf push mydjango -b nginx_buildpack -b python_buildpack. Но, глядя на документы, кажется, что только последний сборочный пакет может запустить команду. Команды из предыдущих пакетов сборки игнорируются. Следовательно, я не могу запустить сервер nginx. Как правильно настроить несколько пакетов компоновки?

Я прочитал CloudFoun dry: nginx для обслуживания контента * stati c поверх Gunicorn (Docker) , но Ответ о наличии двух отдельных приложений с разными маршрутами. Так как это больше для изучения / экспериментов с CF, мне интересно, возможно ли сделать это с помощью одного приложения без выделения содержимого stati c. Спасибо за любую помощь.

1 Ответ

1 голос
/ 09 марта 2020

Для рабочих нагрузок (или чего-то важного) вам не нужно помещать несколько логически отдельных процессов в один контейнер. Основная причина в том, что это затрудняет масштабирование вашего приложения. Допустим, ваше приложение становится популярным, и вам нужно больше обработки Django, чтобы справиться с нагрузкой, и с Nginx & Django в одном контейнере вы должны масштабировать оба вместе. Если они являются отдельными приложениями, их можно масштабировать независимо для каждого логического процесса.

Есть и другие болевые точки:

  • Управление ЦП и памятью сложнее. У вас есть несколько процессов, конкурирующих за один и тот же пул ресурсов. Это особенно сложно для Java приложений, где JVM любит брать все памяти. Это означает, что вам нужно лучше оценивать, чтобы не исчерпать память, и приложение могло взломать sh.
  • Более сложно правильно реагировать на проверки работоспособности. Ваша проверка работоспособности должна точно представлять, что ваше приложение «работает». С несколькими процессами в одном приложении это сложнее.
  • Сложно заставить приложение завершиться, когда один из этих процессов умрет. Это похоже на правильную проверку здоровья. Если приложение не завершится полностью, оно не будет перезапущено, и вы можете оставить половину приложения или сломанное приложение, которое не может быть автоматически перезапущено / исправлено.
  • У вас есть больше гибкость благодаря двум отдельным приложениям, в частности, вы можете обновлять приложения независимо друг от друга.

В любом случае, если вы все еще думаете, что хотите вставить оба в одно приложение, у вас есть несколько вариантов.

  1. Вы можете просто взять под контроль команду запуска с помощью cf push -c или добавив command: в manifest.yml. Это позволит вам переопределить команду, установленную в финальной сборке. Просто будьте осторожны, так как он полностью переопределит то, что установлено в buildpack, поэтому вам действительно нужно знать правильную команду для вызова, иначе ваше приложение не запустится (это особенно сложно с приложениями Java, где команда start может быть сложной) .

  2. Вы можете поместить файл .profile в root каталога вашего приложения (т. Е. Там, где вы установили cf push -p). Этот скрипт будет выполняться до команды, установленной в финальном пакете сборки, и вы можете использовать его для запуска других процессов в фоновом режиме.

Как уже упоминалось выше, получить оба процесса особенно сложно правильно выйти при использовании методов выше. Это один хак, который я нашел, который помогает:

#!/bin/bash
set -e

run_second_process() {
    # insert the command to run the second process here
    #   it should run and keep running (i.e. foreground)
    nginx -c nginx.conf
    # should never get to here, if it does the app crashed
    pkill python  # insert name of your primary process
    # now we are all dead and the container will restart
}

# runs the second process in the background
#   that is important otherwise the primary process will never run
run_updater &

Вам нужно будет найти способы обойти другие недостатки или просто переключиться на использование нескольких приложений. Надеюсь, это поможет!

...