Я знаю, что существуют десятки вопросов по этому поводу, которые в основном вытекают из следования официальному Руководству uWSGI . У меня тоже были проблемы с разрешениями, но другие ответы покрывали их. Я хочу лучше понять, как и когда создается файл сокетов / сокетов Unix. К вашему сведению, это экземпляр AWS ec2 под управлением Amazon Linux 2 AMI.
Руководство uWSGI предлагает вам установить nginx, Django и uwsgi. Затем протестируйте сервер разработки Django и nginx по отдельности. Затем в этом разделе вы проверяете, что uWSGI и nginx работают вместе с сокетом tcp / ip для связи. После этого, все еще не задействовав проект Django, они описывают, как использовать сокеты Unix, а не сокет tcp / ip для связи между nginx и uWSGI. Следуя всей конфигурации nginx / uWSGI, вы запускаете команду из домашнего каталога (по крайней мере для моей конкретной файловой структуры и проекта Django, ~/test_project):
uwsgi --socket test_project/test_project.sock --wsgi-file test.py
Это прекрасно работает, когда решаются некоторые проблемы с разрешениями. Мои вопросы: что такое test_project.sock, когда он создан и какой процесс его создает. Мое лучшее текущее понимание - то, что uWSGI создает его, но почему тогда мы вообще должны включать проект Django (здесь test_project)? Почему бы просто не создать сокет вне папки проекта Django? Используем ли мы синтаксис python, и он является членом какого-то test_project объекта или модуля?
Я знаю, что test_project.sock связан с сокетом Unix. Я думал, что это будет настоящий файл, но это не так. Даже когда я запускаю uWSGI в фоновом режиме и смотрю в соответствующем каталоге, его там нет. Это настолько эфемерно, что оно существует только тогда, когда запрос фактически передается из nginx в uWSGI?
Кроме того, не имея возможности увидеть файл (test_project.sock), как я могу узнать, какие разрешения необходимы для доступа к нему? Я провел несколько тестов и теперь подозреваю, что это связано с разрешениями для файла ~/test_project/test_project/wsgi.py, но у меня нет прямых доказательств.