I'm working on developing a web app using Django, hosted on Gunicorn and Nginx. It's getting a bit inconvenient to run "sudo service nginx restart; sudo service gunicorn restart" every time I make a change to the code. Is there a way I can make them restart automatically whenever I make a change, or make it so the changes show up without having to restart?
You could add the '--reload' argument, as mentioned in the gunicorn documentation.
Restart workers when code changes.
This setting is intended for development. It will cause workers to be
restarted whenever application code changes.
Source: http://docs.gunicorn.org/en/latest/settings.html
Related
I deployed my Django application to the internet and every time after changing codes, I have to run this command to make changes happen:
sudo systemctl restart gunicorn
Is there any way to run this command through codes (for example in views)? or schedule it?
Or is there any way to force Gunicorn restarts after changing in codes?
I have tried Subprocess but I couldn't make it work.
You could use fabric script to restart gunicorn.
Check this link Automate Deployment With Fabric Python
I made so changes in one of my model-forms in my Django apps - I added new input fields for the user. I then tested the changes in my environment and everything works fine. I then committed and pushed the changes to remote repo. I pulled the changes on my production server which runs on AWS. I ran pkill -f runserver in terminal to restart the server, however the changes didn't take place. Only the changes regarding html tags were visible (new labels and etc...).
The changes that weren't present are the ones that come from the model-from: new input fields for the user - those were just missing completely from the template page.
What can be causing this behaviour?
you need to restart gunicorn service every time you make changes to the code.
run sudo systemctl restart gunicorn
Do it and changes will reflect.
After you push changes to the production server you also need to migrate the database changes.
On your local repo (where you make your model changes) you run the makemigrations command
python manage.py makemigrations
And after you fetch your changes on your production server you run the migrate command
python manage.py migrate
It depends on the server you're using : nginx, gunicorn, or apache..
If you setup the server using nginx and gunicorn , you could probably try restarting those services manually, but i'd recommend using something like supervisord to ease out the restart procedure..
If ur using apache, probably use
sudo service httpd restart
If you use supervisor then you need to run
sudo supervisorctl reload
I was having the same problem, this command worked for me on AWS - Ubuntu Server 18.04 LTS.
In all standard django productions setup templates I've seen, gunicorn is run with supervisor, whereas nginx/postgres are not configured under supervisor.
Any reason? Is this required for a production system? If not, why not?
In this architecture, Gunicorn works as the application server which runs our Django code. Supervisor is just a process management utility which restarts the Gunicorn server if it crashes. The Gunicorn server may crash due to our bad code, but nginx and postgres remain intact. So in the basic config we only look after the gunicorn process through supervisor. Though we could do the same for nginx and postgres too.
You need supervisor for gunicorn because it's an simply server without any tools to restart it, run it at system startup, stop it at system shutdown or reload when it crashes.
Postgresql and nginx can take care of themselves in that aspect, so there is no need for them to be running under supervisor.
Actually, you can just use init.d, upstart or system.d to start, stop and restart gunicorn, supervisor is just easier way to handle such small servers like gunicorn.
Consider also that it is common to run multiple django apps on one system, and that requires multiple separated instances of gunicorn. Supervisor will handle them better than init, upstart or system.d
There is also uWSGI server that won't need supervisor, because it has built-in features to handle multiple instances, starting, stopping and also auto-reloading on code change. Look at uWSGI emperor system.
What is the best practice when I have an update for my Django app pushed in my production? Shall I restart both gunicorn and nginx services, with
sudo service gunicorn restart
sudo service nginx restart
or restarting only gunicorn is enough? Finally does the order of the restarts makes any difference if I have to do both the restarts? Thanks!
It entirely depends on how you've configured your box.
To keep downtime to an absolute minimum, I actually load my new release into a different directory on the box while the old release is still running. I create a new virtual environment based on my new release's requirements.txt. Then I start a second instance of gunicorn with the new release running in it (done via supervisord with entries in supervisord.conf), and leave the old instance still running.
I then update my nginx vhost file to point the server to the new release's gunicorn socket, and finally reload nginx. I do a quick check that the new site is up and functioning, and then I stop the old gunicorn instance. If for some reason it's not responding, I switch my nginx config back to point to the old one again, and then go figure out what's wrong.
I do all this using an Ansible script, but here's a great article with some Fabric scripts to do something similar: https://medium.com/#healthchecks/deploying-a-django-app-with-no-downtime-f4e02738ab06
If, on the other hand, you just update your code in-place, then there should be no changes needed to your nginx config, so you shouldn't need to reload it. Just reload gunicorn and you're good to go.
I'm working on a Django webapp that's running under nginx and uWSGI. When I deploy new Django code (e.g., settings.py), do I need to restart uWSGI? If so, why?
Background: I had a scenario where I updated settings.py and some other code and deployed it. I did not see the changes in the webapp behavior until I restarted uWSGI.
Yes, you need to restart the uWSGI process.
Python keeps the compiled code in memory so it won't get re-read until the process restarts. The django development server (manage.py runserver) actively monitors files for changes, but that won't happen by default with other servers. If you want to enable automatic reloading in uWSGI, the touch-reload and py-auto-reload uWSGI arguments might help.