Как переписать URL для структуры папок

Я рекомендую размещать ваши статические файлы в службе хранения, такой как AWS S3, Google Cloud Storage и т. д. Таким образом, он всегда доступен для любого URL-адреса, как у вас (вложенный, поддомен, что угодно)

Пример настройки (может потребоваться еще несколько шагов):

• Измените свой settings.py:

  STATIC_URL = 'https://storage.googleapis.com/your_bucket/static/'

  STATIC_ROOT = os.path.join(BASE_DIR, "staticfiles")

  STATICFILES_DIRS = (os.path.join(BASE_DIR, 'static'),)

• Перед развертыванием приложения запустите manage.py collectstatic --noinput

• Скопируйте файлы из папки staticfiles в службу хранилища и убедитесь, что они общедоступны.
• Разверните свое приложение

P.S. Я считаю, что whitenoise действительно помогает с размерами статических файлов и упрощает развертывание.

Обработка приложения STATIC_URL from django может привести к накладным расходам. Поскольку у вас есть несколько подкаталогов, почему бы не обслуживать статические файлы только из одного из них? Нет необходимости сопоставлять подкаталог при обслуживании статических файлов.

Допустим, если вы установите STATIC_URL следующим образом:

STATIC_URL = "/tool1/static/"

Затем вы можете просто настроить NGINX следующим образом:

server {
    listen 80

    server_name *.myserver.com;

    location /tool1/static/ {
        root /path/to/STATIC_ROOT;
    }

    location / {
        proxy_pass http://localhost:8000;  # <-- No trailing slash to make it work with gunicorn
    }

    location /tool2/ {
        proxy_pass http://localhost:8000;
        proxy_set_header SCRIPT_NAME /tool2;  # <-- For serving in sub path
    }

    location /tool1/ {
        proxy_pass http://localhost:8000;
        proxy_set_header SCRIPT_NAME /tool1; # <-- For serving in sub path
    }

}

И в настройках обновите STATIC_URL на /tool1/static/. Также убедитесь, что ваш STATIC_ROOT указывает на правильный путь, по которому статические файлы будут находиться на сервере. Наконец, перед развертыванием статических файлов вам необходимо запустить collectstatic command, чтобы поместить статические файлы в каталог STATIC_ROOT, а затем перезапустить сервер NGINX.

Обновлять: не рекомендуется использовать жестко заданный URL. Вместо этого в шаблоне вы должны использовать тег {% URL '<url_name> '%} или reverse() в коде Python. Таким образом, django сам разрешит URL-адреса. Когда он находится в /tool1 месте, URL-адреса будут разрешены как /tool1/url_name/, а /tool2/url_name, когда вы находитесь в местоположении /tool2 (на основе SCRIPT_NAME).

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

Всегда используйте один канонический адрес (лично предпочтительно)

Я должен спросить себя: «Почему вы хотите, чтобы ваш инструмент был доступен как в https://myserver.com/tool1, так и в https://tool1.myserver.com?». И на самом деле у меня нет причин, почему он должен быть доступен отдельно в то же время. Так что просто выберите «канонический» адрес и настройте правильные перенаправления:

Если домен канонический:

    server_name myserver.com
    location /tool1/ {
            rewrite ^/tool1/?(.*)$ https://tool1.myserver.com/$1 permanent;
    }

Если папка каноническая:

    server_name tool1.myserver.com
    location / {
            rewrite ^ https://myserver.com/tool1$request_uri? permanent;
    }

Затем на стороне сервера используйте любую опцию один STATIC_URL, соответствующую каноническому адресу (например, /static для поддомена или /tool1/static для папки)

Дополнительные заголовки или параметры URL

Если есть причина (скажите мне, почему!) не использовать перенаправления и использовать оба адреса, то, как упоминал ruddra, можно добавить дополнительные заголовки, а затем использовать их на стороне сервера для создания немного разных страниц:

location /tool1/ {
    <proxy_pass something>
    proxy_set_header SCRIPT_NAME /tool1;
}

Тот же подход можно использовать, если вы выбираете папку в качестве канонического адреса, тогда вы можете избежать жесткого кодирования tool1 в бэкэнде. Тогда, возможно, вы можете использовать либо собственный заголовок, либо дополнительный параметр URL, например ?from=domain[1], который можно обрабатывать в бэкэнде. Здесь у меня нет готового решения, так как для меня был предпочтительнее случай поддомена.