I set up a droplet on digital ocean using the one-click installer. I host my code on a git repo. and I use git pull to merge changes, followed by service gunicorn reload to restart gunicorn. The problem is that everytime I do this and try to visit my site I get an 'internal server error' messages, and after I refresh once or twice the actual page loads.
It is strange because I get the message even if I wait for a while (15 minutes) before visiting the web page, so I'm not sure if I get this because gunicorn was still restarting or for some other reason. Any hints on what might be going on ?
--graceful-timeout or graceful_timeout
Otherwise the workers will stick around until the next request seemingly.
When set to 0 will cause the workers and the master to instantly quit.
Hope it helps.
Related
I run docker-compose up I don't know why but all the previous logs which were part of previous builts, generate again in the terminal. which is why it takes 5 minutes for all the logs to appear and the server to be up and running.
To avoid that previously I used to quit the server, clear the window, remove the terminal and added new terminal and it solved the problem and started the server from fresh. but now it is not working. kindly help I am new to django and docker.
My current set up has a Django project running on Windows 2016 IIS.
The project is hosted on GitHub for collaboration and I would like to set up a GitHub webhook so whenever there's a push to master branch from any of the collaborators, the IIS Server will run a "git pull" to update the project on the server.
What is normally the setup for this?
What I have tried so far is to create an endpoint in the Django project, this endpoint whenever called will run Python subprocess to run "git pull" command in the project itself. However, whenever I run it, it get a 500 response from IIS.
Thanks #VonC for helping.
I have looked to the log (which was the one in XML) but it wasn't much help.
What I'm posting here was my workaround, not exactly to the answer for the question above.
I used django-background-tasks to add the command subprocess.run(['git', 'pull']) as a task to run later (after a few seconds after that by the #background decorator).
Error 500 means the IIS server throws an error.
You need to check said IIS server logs in order to check at what point in the execution of the webhook endpoint script the error occurs.
Django can be run either in Nginx (or some other server, but we are currently going to use Nginx) or with manage.py runserver Django own's server. In both cases I need data integrity and recovery.
For data integrity I need not to terminate (some of) Django requests until they finish. They should not terminate because they should finish started data modification in the DB to preserve data integrity (and no, using SQL transactions is not a solution). They should not terminate as soon as Nginx receives service nginx stop (on Debian Linux) or some other similar command (on other OSes), but finish processing before terminating. How to do this?
For data recovery I want:
create an empty file when the server starts, remove it when the server stops (how to do it both with Nginx and with manage.py runserver?)
When the server starts, if the file is found (indicating a crash of our software), before server starting we need to run my "data recovery" script. How to do this?
A couple things here. First, you should definitely never use runserver in production. Secondly, you don't run really Django in nginx—you run it in a WSGI server, such as uWSGI or Gunicorn. Often, these are run behind nginx, but they don't start and stop when it does.
If you're just trying to make sure that the server doesn't stop while views are still processing, you could definitely do that with uWSGI. There's a pretty good writeup on this subject in the uWSGI documentation called "The Art of Graceful Reloading".
As long as the server is gracefully reloaded, I don't think you need to worry as much about recovery. However, if you still wanted to try that, you'd need to do the empty file deletion in a bash script wrapper—there's no Python code that runs when the server stops.
If I purchase a droplet from digital ocean and install Django on it and get a basic hello world webpage going, how could I run this server and keep it live without a terminal staying open 24/7?
For example, if the droplet I.P. Address was 162.243.250.17:8001, and I entered this code:
python manage.py runserver 162.243.250.17:8001
I'll get the output:
Validating models...
0 errors found
January 31, 2014 - 22:58:23
Django version 1.6.1, using settings 'django_test.settings'
Starting development server at http://162.243.250.17:8001/
Quit the server with CONTROL-C.
But so how do I keep this going even if I close my terminal? I'm going to need a website to stay live.
UPDATE I found the solution
This is the first step if your production server/droplet is running Linux
in order for your website to go live as if it were production ready, you need to install nginx like this:
sudo apt-get install nginx
finally, get your home page to go live with a "Welcome to nginx!" like home page by entering this in your terminal:
sudo service nginx start
That's it!
The next step would be to make it so that the Django development server's address to replace the "Welcome to nginx!" page. I'm going to start working on that now, I'll keep this thread updated with the solution.
This is not the way to run django based webserver. You need to use apache/nginx.
If you use nginx you can combine it with wsgi container like gunicorn and supervisord.
For example, look here http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/ or search for these terms.
What eran said is absolutely right: you would never use the built in django server for anything in production, and use nginx or gunicorn/uwsgi.
However, you seem to be learning Django at this point. So, even if you just close the terminal (if you are SSH-ing) or close the browser, the program should run as long as you do not press ctrl + c, or kill the running server. However, you will find out that it crashes a lot and is very slow.
Learning nginx and uwsgi is too much work at this point. Learn django properly on your laptop first, and when you feel comfortable enough, then maybe deploy on digital ocean. Why spend money, albeit it is pretty cheap at $5.
I've got several questions. I have no idea how the heck to deploy...
After doing "svn up" on my production server, I'm not sure how to "refresh" my server so that the changes are reflected when you visit it. What can I do to refresh my server to see the changes in production? (I tried rebooting.)
I also noticed that some of the files that I changed weren't truly updated. I deleted a file and saw that doing "svn up" would bring the file back. I went back and deleted everything in the web app's folders, including the svn files (probably a mistake). (I should be safe since I have the prod revisions on the test server, I assume...) So, how can I bring these files back?
I need all the advice and resources on this that I can get. Feel free to post anything else that will get me through this process.
It depends how you run your django up. If you're serving with mod_python/modwsgi, a simple apache restart does the trick.
If you're datamodel changed, you may need to call south command migrate.
On most Linux-Systems this can be done with service apache2 restart
You can do the svn up, manage.py migrate and service apache2 restart with fabric
Fabric helps you to automate to execute shell commands over ssh.
If you are deploying on mod_wsgi you can simply touch the .wsgi file and it will reload the app without having to restart your whole server/httpd/etc