This is well known topic, on how to setup, serve MEDIA Files, but there is a lot of no no to serving them in production, this is just one example from answered question on SO,
Django does not serve MEDIA_ROOT by default. That would be dangerous
in production environment. But in development stage, we could cut
short. Pay attention to the last line. That line enables Django to
serve files from MEDIA_URL. This works only in developement stage
Obviously there is a lot of web application that are handling this, I have a field in which I'm expecting a lot of CV to be uploaded, my concern are corrupted files, so is there a common pattern on how to handle this?
What you are saying is recommended against, but if you would like to anyways, there is a package called dj-static that does exactly what you are asking.
dj-static on Github
Related
What should I know about saving files in production? I need to save lots media which are pdf files. The only thing I know so far, is that I shall rename pdf files into my own naming system (for example by overwriting storage in django). But what else is important ?
Or that's all, just saving all files like 1.pdf,2.pdf,3.pdf,4.pdf.. in one media folder and it will work in long term without any other tricks and optimization? I am using django1.8 and python 2.7, but I guess it's very general question regarding running production server at all .
I hope it's not off topic, as far I faced the lack of information on the issue.
Here are some tips:
Follow a directory structure similar to this: appname/%Y/%m/%d.
Use AWS S3, or another storage service, for your media and static files.
Compress files to reduce size.
Use whitenoise, or a similar package, to serve static files in production.
Note: These tips are not solely for media, but also static files.
I am using DJango 1.8 and python 3.4.3, and I have been running my app on Debug mode, and found a way to show images inside a directory configured on MEDIA_ROOT, this was my first question and the solution I have found: How to upload and show images in DJango. But reading the docs I found that that solution is not suitable for a served app, so, if I stop using "Debug=True" the images will not be displayed, and I have to use one of the options exposed on this link: Static files on deployment but I don't have money to pay another server, I just can pay my hosting on pythonanywhere, and for the option to use the same server for the images, I don't have idea how to automate the collectstatic and also don't know how to trigger it when an user uploads a new image.
I have used ASP.NET and PHP5 and I didn't had problems with the images in none of them, so, I have two questions:
Is there an easy way to show images URL's?
Is there a high risk security problem if I deploy my app with DEBUG=True?
I hope you can help me, because I find this ridiculous, probably is for better security, but it just not make sense for a framework, instead of making the work easier it make it more difficult and stressful.
Django runserver is not intended for serving up static files in a production environment. It should be limited to development and testing environments.
If you are intending to use django's runserver to server up static files with DEBUG=False then use the --insecure flag.
You should never deploy a site with DEBUG = True due to security implications.
Static files and media assets are 2 different things.
Static Files
Static files are things like images you created and files that come with 3rd party apps you have installed (e.g. django-cms). These files include images, css and javascript files etc.). So you need to have a settings.STATIC_ROOT for this.
python manage.py collectstatic collects static files from different locations and puts them all in a single folder.
Media Files
Media files are things the user uploads (e.g. photos, documents etc.). So you have a settings.MEDIA_ROOT for this. collecstatic won't do anything to media files, they will just be there already once the user uploads them.
Serving up static and media files in production
Frameworks like Django aren't going to cover automatic production server configuration - that is something else you will have to learn unfortunately.
There are a lot of good guides around e.g. this one to help you get started serving media and static files in production.
Regarding server costs, I'm sure you can find a host to give you some free credit, or pay $5/month for a server somewhere... try lowendbox
Here is a guide from pythonanywhere regarding media and static files: https://help.pythonanywhere.com/pages/DjangoStaticFiles/
1) in urls.py add:
(r'^media/(?P<path>.*)$', 'django.views.static.serve',
{'document_root': settings.MEDIA_ROOT, 'show_indexes': True}),
and open url http://myhost.com/media/
2) Never deploy a site into production with DEBUG turned on, DEBUG=True is a security issue,
Okay so i have shared hosting so it means i have access to just about nothing so i'm having problems setting up my django application.
Looking at google searches there is a way to do it using a .htaccess and .wgsi file but I'm having no luck. My knowledge with anything like this is low as i normally use php.
So far i have added some code into the htaccess file and it always comes up with this error..
Not Found
The requested URL /dispatch.wsgi/ was not found on this server.
You should take a look at this :
In this section of django documentation they explain the how to :)
Running Django on a Shared-Hosting Provider with Apache
Many shared-hosting providers don’t allow you to run your own server daemons or edit the httpd.conf file. In these cases, it’s still possible to run Django using Web server-spawned processes.
have a nice day :)
Do you have the dispatch.wsgi on the specific path? it should be somewhere like the public folder that serves your static files, like /public_html or /www.
I have used shared hosting for django from a small orange. I got mine working by following this tutorial of theirs, maybe working for you too.
I have picked up python/django just barely a year. Deployment of django site is still a subject that I have many questions about, though I have successfully manual deployed my site. One of my biggest questions around deployment is what measures can I take to safeguard the source code of my apps, including passwords in django's setting.py, from others, especially when my site runs on a virtual hosting provided by some 3rd party. Call me paranoid but the fact that my source code is running on a third-party server, which someone has the privileges to access anything/anywhere on the server, makes me feel uneasy.
There is almost no scenario where your hosting provider would be interested in your source code. The source code of most websites just isn't worth very much.
If you really feel it is necessary to protect your source code, the best thing to do is serve it from a system that you own and control physically and have exclusive access to.
Failing that, there are a few techniques for obfuscating python, the most straightforward of which is to only push .pyc files and not .py files to your production server. However, this is not standard practice with Django because theft of web site source code by hosting providers is not really an extant problem. I do not know whether or not this technique would work with Django specifically.
If someone has the privileges to access anything/anywhere on the server you can't do much, because what you can do others can do too, you can try some way of obfuscation but that will not work. Only solution is NOT to use such shared repository.
Edit: options
Keep working with shared repository if your data is not very sensitive
Use dedicated hosting from companies like rack-space etc
Use AWS to run your own instance
Use google-app-engine server but that may require a DB change
Run your own server (most secure)
While your source code's probably fine where it is, I'd recommend not storing your configuration passwords in plaintext, whether the code file is compiled or not. Rather, have a hash of the appropriate password on the server, have the server generate a hash of the password submitted during login and compare those instead. Standard security practice.
Then again I could just be talking out my rear end since I haven't fussed about with Django yet.
Protecting source code is not that important IMHO. I would just deploy compiled files and not worry too much about it.
Protecting your config (specially passwords) is indeed important. Temia's point is good.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm about to deploy a mediumsized site powered by Django. I have a dedicated Ubuntu Server.
I'm really confused over which serversoftware to use. So i thought to myself: why not ask stackoverflow.
What i'm looking for is:
Easy to set up
Fast and easy on resources
Can serve mediafiles
Able to serve multiple djangosites on same server
I would rather not install PHP or anything else that sucks resources, and for which I have no use for.
I have heard of mod_wsgi and mod_python on Apache, nginx and lighty. Which are the pros and cons of these and have i missed someone?
#Barry: Somehow i feel like Apache is to bloated for me. What about the alternatives?
#BrianLy: Ok I'll check out mod_wsgi some more. But why do i need Apache if i serve static files with lighty? I have also managed to serve the django app itself with lighty. Is that bad in anyway? Sorry for beeing so stupid :-)
UPDATE: What about lighty and nginx - which are the uses-cases when these are the perfect choice?
Since I was looking for some more in-depth answers, I decided to research the issue myself in depth. Please let me know if I've misunderstood anything.
Some general recommendation are to use a separate webserver for handling media. By separate, I mean a webserver which is not running Django. This server can be for instance:
Lighttpd (Lighty)
Nginx (EngineX)
Or some other light-weight server
Then, for Django, you can go down different paths. You can either:
Serve Django via Apache and:
mod_python
This is the stable and recommended/well documented way. Cons: uses a lot of memory.
mod_wsgi
From what I understand, mod_wsgi is a newer alternative. It appears to be faster and easier on resources.
mod_fastcgi
When using FastCGI you are delegating the serving of Django to another process. Since mod_python includes a python interpreter in every request it uses a lot of memory. This is a way to bypass that problem. Also there is some security concerns.
What you do is that you start your Django FastCGI server in a separate process and then configures apache via rewrites to call this process when needed.
Or you can:
Serve Django without using Apache but with another server that supports FastCGI natively:
(The documentation mentions that you can do this if you don't have any Apache specific needs. I guess the reason must be to save memory.)
Lighttpd
This is the server that runs Youtube. It seems fast and easy to use, however i've seen reports on memoryleaks.
nginx
I've seen benchmarks claiming that this server is even faster than lighttpd. It's mostly documented in Russian though.
Another thing, due to limitations in Python your server should be running in forked mode, not threaded.
So this is my current research, but I want more opinions and experiences.
I'm using Cherokee.
According to their benchmarks (grain of salt with them), it handles load better than both Lighttpd and nginx... But that's not why I use it.
I use it because if you type cherokee-admin, it starts a new server that you can log into (with a one-time password) and configure the whole server through a beautifully-done webmin. That's a killer feature. It has already saved me a lot of time. And it's saving my server a lot of resources!
As for django, I'm running it as a threaded SCGI process. Works well. Cherokee can keep it running too. Again, very nice feature.
The current Ubuntu repo version is very old so I'd advise you use their PPA. Good luck.
As #Barry said, the documentation uses mod_python. I haven't used Ubuntu as a server, but had a good experience with mod_wsgi on Solaris. You can find documentation for mod_wsgi and Django on the mod_wsgi site.
A quick review of your requirements:
Easy to setup I've found apache 2.2 fairly easy to build and install.
Fast and easy on resources I would say that this depends on your usage and traffic. * You may not want to server all files using Apache and use LightTPD (lighty) to server static files.
Can serve media files I assume you mean images, flash files? Apache can do this.
Multiple sites on same server Virtual server hosting on Apache.
Rather not install other extensions Comment out anything you don't want in the Apache config.
The officially recommended way to deploy a django project is to use mod_python with apache. This is described in the documentation. The main pro with this is that it is the best documented, most supported, and most common way to deploy. The con is that it probably isn't the fastest.
The best configuration is not so known I think. But here is:
Use nginx for serving requests (dynamic to app, static content directly).
Use python web server for serving dynamic content.
Two most speedy solutions for python-based web server is:
cogen
fapws2
You need to look into google to find current best configuration for django (still in development).
I’m using nginx (0.6.32 taken from Sid) with mod_wsgi. It works very well, though I can’t say whether it’s better than the alternatives because I never tried any. Nginx has memcached support built in, which can perhaps interoperate with the Django caching middleware (I don’t actually use it, instead I fill the cache manually using python-memcache and invalidate it when changes are made), so cache hits completely bypass Django (my development machine can serve about 3000 requests per second).
A caveat: nginx’ mod_wsgi highly dislikes named locations (it tries to pass them in SCRIPT_NAME), so the obvious ‘error_page 404 = #django’ will cause numerous obscure errors. I had to patch mod_wsgi source to fix that.
I'm struggling to understand all the options as well. In this blog post I found some benefits of mod_wsgi compared to mod_python explained.
Multiple low-traffic sites on a small VPS make RAM consumption the primary concern, and mod_python seems like a bad option there. Using lighttpd and FastCGI, I've managed to get the minimum memory usage of a simple Django site down to 58MiB virtual and 6.5MiB resident (after restarting and serving a single non-RAM-heavy request).
I've noticed that upgrading from Python 2.4 to 2.5 on Debian Etch increased the minimum memory footprint of the Python processes by a few percent. On the other hand, 2.5's better memory management might have a bigger opposite effect on long-running processes.
Keep it simple: Django recommends Apache and mod_wsgi (or mod_python). If serving media files is a very big part of your service, consider Amazon S3 or Rackspace CloudFiles.
There are many ways, approach to do this.For that reason, I recommend to read carefully the article related to the deployment process on DjangoAdvent.com:
Eric Florenzano - Deploying Django with FastCGI: http://djangoadvent.com/1.2/deploying-django-site-using-fastcgi/
Read too:
Mike Malone - Scaling Django
Stochastictechnologies Blog: The perfect Django Setup
Mikkel Hoegh Blog: 35 % Response-time-improvement-switching-uwsgi-nginx
Regards
In my opinion best/fastest stack is varnish-nginx-uwsgi-django.
And I'm successfully using it.
If you're using lighthttpd, you can also use FastCGI for serving Django. I'm not sure how the speed compares to mod_wsgi, but if memory serves correctly, you get a couple of the benefits that you would get with mod_wsgi that you wouldn't get with mod_python. The main one being that you can give each application its own process (which is really helpful for keeping memory of different apps separated as well as for taking advantage of multi-core computers.
Edit: Just to add in regards to your update about nginix, if memory serves correctly again, nginix uses "greenlets" to handle concurrency. This means that you may need to be a little bit more careful to make sure that one app doesn't eat up all the server's time.
We use nginx and FastCGI for all of our Django deployments. This is mostly because we usually deploy over at Slicehost, and don't want to donate all of our memory to Apache. I guess this would be our "use case".
As for the remarks about the documentation being mostly in Russian -- I've found most of the information on the English wiki to be very useful and accurate. This site has sample configurations for Django too, from which you can tweak your own nginx configuration.
I have a warning for using Cherokee. When you make changes to Django Cherokee maintains the OLD process, instead of killing it and starting a new one.
On Apache i strongly recommend this article.
http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl
Its easy to setup, easy to kill or reset after making changes.
Just type in terminal
sudo /etc/init.d/apache2 restart
and changes are seen instantly.