CODEWITHSUNDEEP
djangoapacheweb-deployment
Joshua Gevirtz
Joshua Gevirtz

Reputation: 401

Strategies for deploying Django App

I have a question that is probably more general than django-related development. The background is quite simple:

I am working on a project whose pages are mostly associated with a web application (this is what I am using Django for). In addition to the app-related pages, however, there are quite a few auxiliary pages (like a landing page, a faq page, a contact page, etc.) that have basically nothing to do with the web app.

What is the standard strategy for deploying such a project? It seems flawed to route requests to these static pages through Django. What seems to make sense is running two servers: one responsible for running the Django app and a a separate server that is responsible for serving the static pages (including, perhaps, the static content used by the app portion of the web site) .

What are some guiding principles that should be employed when making these decisions?

Upvotes: 0

Views: 103

Answers (1)

Lie Ryan
Lie Ryan

Reputation: 64923

It's not uncommon to run Django side by side with a static site or another CMS.

You would need a front end server to route the request to either the static content or a CMS.

There are two common strategies:

  1. Use URL prefix to determine where to route (e.g. example.com/static/ to static files and example.com/ to Django). You would need a front end server to route the request to either the static content or a web app/CMS written in another framework/language (this is configured with Alias directive in Apache).

  2. Put the application server and static file server on separate domain/subdomain (e.g. static.example.com to static and app.example.com to Django). You can do this by configuring a front end server to serve on a single machine (this is configured with VirtualHost on Apache) or as separate machine. In either case, you'd need to configure the DNS to point to your subdomains to the right machine(s).

The former is simpler to setup, but the latter allows you to scale better.

Servers commonly used for front-ending an application server includes Apache, Nginx, or uWSGI, but pretty much any production-quality web server can do it.

In fact Django's deployment documentation (e.g. Apache) would always instruct you to have your static files served by the front end server even in a Django only installations, as Django weren't designed for efficiently serving static contents unlike the front end web servers.

The django.contrib.staticfiles app is there to make it possible for Django to refer to a static file hosted on a different server and easily switch between serving static contents with Django's built-in server during development but with the front end server on production.

Upvotes: 4

Related Questions