CODEWITHSUNDEEP
pythondjangoproduction
space earth
space earth

Reputation: 417

Django deploying website

I have made a website with django. I want to deploy this application to production.

Now I am confused about several things: at the time of the development I can run my application using the command: python manage.py runserver IP_OF_SERVER:PORT. Now by this approach I can do everything. My tool (website) will only be used locally. Is it fine that I deploy my website with this command only? Is is necessary to do django production processes and if it is necessary how to do that? I am new to django. Please help me to understand.

Upvotes: 0

Views: 209

Answers (2)

be_good_do_good
be_good_do_good

Reputation: 4441

If you want to setup your Django production server through IIS in Windows server (If users are less, you can even use normal Windows 7 or 10 professional machines as well). This video can help you do it step by step

https://www.youtube.com/watch?v=kXbfHtAvubc

I have brought up couple of production websites this way.

Although the one you are trying to do also works, but the only problem with your approach is that you should take care that console is never closed by anyone or you accidentally. But there are lot more hidden problems, usually for production, this is not recommended.

To avoid accidental closures, you can do below in Windows (running it as a service):

For this approach, you need pywin32 needs to be installed, install it from here: https://sourceforge.net/projects/pywin32/files/pywin32/Build%20217/

import win32service
import win32serviceutil
import win32event
import subprocess
import os

class PySvc(win32serviceutil.ServiceFramework):

    # you can NET START/STOP the service by the following name
    _svc_name_ = "Name your Service here"
    # this text shows up as the service name in the Service
    # Control Manager (SCM)
    _svc_display_name_ = "External Display Name of your service"
    # this text shows up as the description in the SCM
    _svc_description_ = "Description what this service does"

    def __init__(self, args):
        import platform
        win32serviceutil.ServiceFramework.__init__(self, args)
        # create an event to listen for stop requests on
        self.hWaitStop = win32event.CreateEvent(None, 0, 0, None)

    # core logic of the service
    def SvcDoRun(self):
        os.chdir('your site root directory')
        subprocess.Popen('python manage.py runserver IP:PORT')
        # if you need stdout and stderr, open file handlers and keep redirecting to those files with subprocess `stdout` and `stderr`

    # called when we're being shut down
    def SvcStop(self):
        # tell the SCM we're shutting down
        self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)

        # fire the stop event
        win32event.SetEvent(self.hWaitStop)


if __name__ == '__main__':
    win32serviceutil.HandleCommandLine(PySvc)

Upvotes: 1

Noufal Ibrahim
Noufal Ibrahim

Reputation: 72755

Usually, these kinds of things are deployed in a three tier fashion.

Here, the general approach is like so

[Database] <-(db calls)-> [Django app] <- wsgi -> [gunicorn] <- http -> [nginx] <- http -> public

your application is the "Django app" block over here. You could run it with something like manage.py runserver but that's a very lightweight toy server which can't really handle high levels of traffic. If you have a request that takes 1ms to handle and 100 users try to make the same request, the last client will have to wait 100ms before she can get the response. It's easy to solve this by just running more instances of your application but the dev server can't do that.

A so called "app server" like gunicorn will allow you to run a more powerful web server for your application that can spawn off multiple workers and handle some kinds of mischievous traffic patterns.

Now, even gunicorn can be bested by a high performance server especially for serving static assets like images, css, js etc. This is something like nginx. So, we set up our thing to have nginx facing the world and serving all static assets directly. And request to the actual application will be proxied to gunicorn and that will be served by your actual app.

This is not as complex as it sounds and you should be able to get something running within a day or so. All the technologies I've mentioned have substitutes with different characteristics. This is a good tutorial on how to get things going and what to look out for during deployment.

Upvotes: 4

Related Questions