I'm trying to setup a webserver with nginx, uwsgi and django.
nginx works and it serves the files in /srv just like I intended to. However I can't get uwsgi to work properly. My biggest problem is that I used this tutorial and they don't seem to use the version of uwsgi that I use.
At one point they call uwsgi --http :8000 --wsgi-file test.py, but my uwsgi has neither the --http long option, nor --wsgi-file long option. uwsgi --version prints 2.0.7-debian.
What can I call instead of --wsgi-file?
UPDATE:
This works fine, i.e. I can see my website on localhost on port 8000:
python3 manage.py runserver 0.0.0.0:8000
However this does not:
uwsgi --http :8000 --module django_test.wsgi
It will complain, that it doesn't know the long option --http as well as the long option --module. It all seems to boil down to uwsgi, which on my machine just doesn't behave as it does everywhere else.
uWSGI installed from debian packages doesn't have any built-in plugins, and for that parameters to work, you will need:
http plugin for --http parameter
python plugin for --module (or any wsgi related) parameter
You can fix this in 2 ways: installing all required plugins (uwsgi-plugins-all package will install all available plugins on debian) and loading them explicitly (--plugin http and --plugin python) or by replacing uWSGI by fully featured one (sudo pip install uwsgi will do that). Second solution will tie your uWSGI up to certain python version, for first one, you can just load another python plugin (python3 for example).
Related
So I am using a docker for this python chat app project.
I originally had python manage.py runserver 0.0.0.0:8000 as my command in docker-compose.
I found that I should switch to gunicorn if I want to deploy my app on web (like heroku). The tutorial I found say simply change the command in docker-compose to gunicorn myproject.wsgi -b 0.0.0.0:8000. I did that, and all the websocket connections broke. There's a fail to send due to websocket is still in CONNECTING state, then after a while handshake fails with a status code of 404. All the setup were the same as before, except that one line. Just wondering what else I need to change to make websocket work with gunicorn? Thanks
EDIT: after some digging on the internet it seems that gunicorn wasn't supposed to be run with websocket (wsgi asgi difference I suppose?) If anyone could tell me something I could use instead of gunicorn for web server it would be extremely appreciated, or if there's any way I can run gunicorn with my django channels still working? Thanks!!
When using ASGI, for asynchronous servers (websockets), you should use an asynchronous server, like Daphne or Uvicorn, the Django documentation has examples on how to deploy for both of them.
If you want to use uvicorn directly you could do something like:
uvicorn myproject.asgi:application --host 0.0.0.0 --port 8000
You can also run uvicorn through gunicorn using the worker class:
gunicorn myproject.asgi:application -k uvicorn.workers.UvicornWorker -b 0.0.0.0:8000
When starting python web application using gunicorn command, like gunicorn -b 127.0.0.1:8080.
It prompts cannot find packages like numpy which ran default Python interpreter. I added pythonpath to gunicorn command, but it doesn't work. BTW, I created a virtual env in the application folder.
Hope someone could provide a solution.
The problem is you are using default python to execute gunicorn. Either you activate your virtualenv and then execute the gunicorn -b 127.0.0.1:8080 or else you can use the following command
/ABSOLUTE_PATH/vitual_python_env/bin/gunicorn -b 127.0.0.1:8080
I have a django website setup and configured in a python virtual environment (venv) on Ubuntu and all is working fine. Now in order to to run my server on port80 I need to use "sudo" which does not execute in the context of the virtual environment, raising errors (i.e no module named django ...)
Is there a way to get "sudo" to execute in the context of the python virtual environment?!
No, you don't need to do this. You shouldn't be trying to run the development server on port 80; if you're setting up a production environment, use a proper server.
As #DanielRoseman said you should not be using the Django development server in production.
But if you need to run the development server on port 80 you have to reference the use the virtual environment python executable directly.
sudo ../bin/python manage.py runserver localhost:80
This should be the solution.
Even tho I really don't recomment doing this. If you need sudo within Python you are probably on a wrong way.
this did the trick:
$ sudo -- sh -c './venv-bin-path/activate; gunicorn <params> -b 0.0.0.0:80'
This following codes are inside a uWSGI configuration file called flask1.ini:
[uwsgi]
socket = /tmp/flask1.sock
chmod-socket = 777
evn = PRODUCTION=TRUE
module = indy
callable = app
processes = 4
threads = 2
logto = /var/indylog
The production server is set up on ubuntu 14.04 using uWSGI and nginx for Flask application.
I wrote a new module that uses Python 2.7 and it runs without any error on my local ubuntu 14.04 virtualenv (Flask development server) and the same nginx and uWSGI set up as the production environment. However, when I deployed the same code live on production server, it gives a bunch of syntax errors, I am trying to figure out why this is the case.
I run python --version on my local desktop and production server, they are both Python 2.7.6.
My questions: with the above uWSGI configuration on production server, which Python is being used? The machine Python or virtualenv Python?
To be precise, neither. uwsgi does not actually run the Python binary, it uses libpython directly. It just follows your system's LD_LIBRARY_PATH to find the corresponding libpython library and this is normally not affected by virtualenv.
What is affected by virtualenv, however, is the location from which uwsgi will load your packages. You will still need to add a line in your uwsgi.ini to specify the path your virtualenv like this:
virtualenv = /path/to/your/virtualenv
If you wish to configure uwsgi to use different versions of libpython, you will need to build the corresponding plugin for each version and specify it in uwsgi.ini. You can find more information about this here
At first, you have to create Python 3 environment for your source code:
virtualenv -p /usr/bin/python3 path_to_your_project/env
And install packets required:
cd path_to_your_project
source env/bin/activate
# you can use pip to install packets required, e.g:
pip install -r requirements.txt
Finally, add virtualenv to your uwsgi.ini file:
virtualenv = path_to_your_project/env
Install uwsgi in the virtualenv to use whichever Python version the env is configured with. /path/to/env/bin/uwsgi --ini /path/to/flask.ini. Instead of global uwsgi path/to/your/flask.ini, which would use the Python version that the system installed.
I'm now working on a Web application which is based on Django-1.8.2 and on virtual env provided by Python-3.4.3 of Ubuntu-15.04.
My app. is now working on the development server, and has been successfully deployed using mod_wsgi-4.4.11 (pip installed) and Ubuntu's Apache. That is, after collecting static files and modifying the file permissions of db.sqlite3, I did ...
sudo ../bin/python manage.py runmodwsgi --setup-only --port=80 --user www-data --group www-data --server-root=/etc/mod_wsgi-express-80
sudo /etc/mod_wsgi-express-80/apachectl start
to have a working server.
I'd like the daemons to start up on boot-up automatically, but I have no luck in writing an init.d script or a config file. Probably, an utterly new way is required for the systemd of 15.04. Any suggestions will be welcome.
Looks like the question is about Ubuntu systemd launcher rather than django + mod_wsgi...
After struggling with init.d scripts, I have moved over to systemd service file:
/lib/systemd/system/apache_mod_wsgi.service
[Unit]
Description=apache2 with mod_wsgi
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/mod_wsgi-express-80/apachectl start
ExecStop=/etc/mod_wsgi-express-80/apachectl stop
[Install]
WantedBy=multi-user.target
With this file saved, I killed the native apache2 service and enabled the new service...
fukuda#ubuntu:~% sudo update-rc.d apache2 remove
fukuda#ubuntu:~% sudo systemctl enable apache_mod_wsgi.service
fukuda#ubuntu:~% sudo reboot
The daemons have started successfully, and the django application seems working properly (that is, is responding in an exactly same manner with "manually started" version and the development server.
The only concern is that dmesg would not report the starting up of the service.
If you searched for how to start a mod_wsgi-express with init.d or the likes instead of with django, first have a look at https://pypi.python.org/pypi/mod_wsgi#running-mod-wsgi-express-as-root.
you should use setup-server:
mod_wsgi-express setup-server wsgi.py --port=80 \
--user www-data --group www-data \
--server-root=/etc/mod_wsgi-express-80
This should be the prerequisite to OP's answer.