I have a django project which I want to deploy on apache2 Http Server.
However, I want to automatically copy all the python files from some directory to apache srv directory which is /srv/www/myproject. Is there any automatic python tool which could solve the purpose.
I have looked into DistUtils and setup.py but I am unsure about how I would copy all .py files (along with directory structure) to the apache directory.
Any help will be appreciated!!!
Take a look to fabric, it is a great tool to do automatic deployments
From the django tutorial:
If your background is in PHP, you're probably used to putting code
under the Web server's document root (in a place such as /var/www).
With Django, you don't do that. It's not a good idea to put any of
this Python code within your Web server's document root, because it
risks the possibility that people may be able to view your code over
the Web. That's not good for security.
Put your code in some directory outside of the document root, such as
/home/mycode.
For copying files, you can use something as simple as FTP/SCP which you can automate; or you can use more full blown deployment options like fabric (see this blog entry for a step-by-step guide on fabric + virtualenv + apache mod_wsgi).
You can use any tool to automate the task; but please put the code in the appropriate non-web browsable directory.
Related
I am running the celery flower application (https://github.com/mher/flower) in my server. I installed this application in my Python LAMP server using the following command:
pip install flower
Now I want to do some modifications in the application such as functionality and layout. I want to do it by placing a copy of the application files in my /var/www/html public folder where all of my other applications are placed so as not to disturb the original application and not having to go into the system files like ../lib/......./dist/flower. I have been developing applications in django previously and and in django, we can just put a copy of application files in our root applications folder and do modifications in it and the system reads the new copy of the files instead of original installation (pretty clean and clear method). I was hoping to have something like this for this application also? Any suggestions?
Firstly, none of your application files should be in /var/www/html. That's for documents served directly by the webserver, not for code.
To answer your question though, if you want to modify a project you should fork it on github, make your changes there, and install from the forked repo in pip.
Hi I am a newbie to Django AND Python. Working currently on a dummy project using Django 1.9. So following the excellent Django Documentation I could complete the deployment using apache/mod_wsgi and it is running on a test web server on my local machine.
But I am wondering about the Python source files :
I have given the path to my development directory - say /Python-labs/mysite/ to mod_wsgi and apache configuration ( httpd.conf ) files. This development directory obviously contains all the .py files - the Python source files.
No-where in the documentation i found any mention to remove the source files etc. So I googled but could not get anything as a standard step to remove source files from the production deployment.
Got this - the closest to what I am asking for :
Django Remove Source Files
Django Deployment Without Source Code
but again it does not make it crystal clear about the questions below :
My Questions :
Is it a standard step in Django deployment to remove source files or not ?
( or Did I miss something very obvious from the documentation ? )
Is it Ok if we put .py files on production server ? Or is it intended that way ?
Thanks a lot in Advance !
It is typical to deploy source files with Django. As long as the project is set properly (__init__.py included for all project/app directories) then Django will compile .py files to .pyc.
To answer your questions -
1. Don't serve your production files directly; use a good VCS to push files to your production server or, if quick and dirty, copy your project to your production server. But uncompiled .py files are standard for most Django projects.
2. Yes.
For more insight, this question may help.
I am following a step-by-step tutorial blog on the flask micro framework for python.
I bumped into an issue, when they require me to 'setup' a configuration file in the root of the application folder, so it can easily be accessible if needed.
They called it config.py.
My question is, if the local path to my application is /home/test/application1/, should I create the file inside the ./application1/ directory? What gets me confused in this somewhat obvious question is that I did a quick search for other config.py files in the local directory inside /home/test/application1/, where I found 4 other files. There were in the following directories:
/home/test/application1/flask/lib/python2.7/site-packages/flask/testsuite/config.py
/home/test/application1/flask/lib/python2.7/site-packages/flask/config.py
/home/test/application1/flask/local/lib/python2.7/site-packages/flask/testsuite/config.py
/home/test/application1/flask/local/lib/python2.7/site-packages/flask/config.py
So should I create a new config.py file in the directory that I first mentioned or should I add some lines in one of the previously created config.py files.
Here is the source of the step-by-step tutorial:
It is at the beginning, right after Configuration.
Unlike other frameworks, Flask does not have a lot of rules, in general you can implement things in the way they make sense to you.
But note that the other config.py files that you found are all in the virtual environment, and are all scripts that come with Flask. They have nothing to do with the application configuration.
I wrote the tutorial you are following. In the tutorial I'm putting config.py outside of the application package. This is what I like, I consider the configuration separate from the application. My thinking is that you should be able to run the same application with different configuration files, so that for example, you can have a production configuration, a testing configuration and a development configuration, all different.
I hope this helps.
I'm uploading my first Django project to a Linux server, where I should put my project in the filesystem?
With a PHP, or ASP project, everything goes into /var/www, would it be ok to do the same and add my Django project to the /var/www folder?
In the Django tutorial it states:
Where should this code live?
If your background is in PHP, you're probably used to putting code under the Web server's document root (in a place such as /var/www). With Django, you don't do that. It's not a good idea to put any of this Python code within your Web server's document root, because it risks the possibility that people may be able to view your code over the Web. That's not good for security.
Put your code in some directory outside of the document root, such as /home/mycode.
File Hierarchy System
#Andy Hayden really states where not to place ones code. The File Hierarchy System (FHS) implicates the following structure; PATH maps to PACKAGE or PROVIDER (It is recommended that parties providing multiple packages should use PROVIDER/PACKAGE) :
/etc/opt/PATH # FHS location for /opt configuration files
/opt/PATH # FHS location for PROVIDER or PACKAGE name
/var/opt/PATH # FHS location for /opt variable storage
The FHS expects /opt/PATH to contain all the material necessary for the successful execution of ones package so it seems prudent to setup the following symbolic links
/etc/opt/PATH to /opt/PATH/etc
/var/opt/PATH to /opt/PATH/var
This provides a good basis but Django projects have extraneous requirements that the above structure does not fully meet.
Static Files
Static files are deployed when one runs python manage.py collectstatic to the STATIC_ROOT which should point to the web server root for static delivery, usually /var/www/PATH.
One could link /var/www/PATH symbolically to /opt/PATH/static
but this is typically a bad idea; Consider the case that you have a misconfigured server and a user goes to www.domain.tld/../ and copies your work.
Settings
If you created your project with django-admin create-project WEBSITE the you will typically have a setup.py file under the WEBSITE folder.
PROJECT/
WEBSITE/
setup.py
...
If you converted this settings module into a package, or you used some wrapper around django-admin e.g. django-cms-create etc.
PROJECT/
WEBSITE/
settings/
__init__.py # from .settings import *
settings.py
...
You might symlink /etc/opt/PATH to /opt/PATH/WEBSITE/settings instead of /opt/PATH/etc as described above. I can't think of a practical reason for doing so though... YMMV.
Media
Media, typically provided by ones websites users, are placed into MEDIA_ROOT. It seems prudent to map /var/opt/PATH to /opt/PATH/media in this case.
Virtual Environments
/opt/PATH/env seems the most logical location. /var/env/PATH also seems sensible but is probably better suited as a symbolic link to /opt/PATH/env.
Since a virtual environment is neither an application nor a library the locations /opt/bin and /opt/libs would not do for this. /env/ or /pyvenv/ does not conform to the FHS.
Whiskey
If you're using mod_wsgi with Apache the an invocation similar to python manage.py runmodwsgi --server-root /etc/opt/PATH --setup-only is probably preferable since it places the Apache control commands into the FHS compliant locations, granted they are more cumbersome to invoke in this case.
Home
To my understanding /home was traditionally used by PHP developers when they were hosting multiple sites upon the same server. If you're using Django you're probably serving your site from a dedicated machine and this structure looses a bit of favour in this case... YMMV.
I'm trying to understand what paste script and paster are. The website is far from clear.
I used paster to generate pre-made layouts for projects, but I don't get the big picture.
As far as I understand, and from the wikipedia entry, it says it's a framework for web frameworks, but that seems reductive. paster create seems to be able to create pre-made layouts for setuptools/distutils enabled packages.
What is the problem (or set of problems) it's trying to solve?
Paste got several components:
Paste Core: various modules to aid in creating wsgi web apps or frameworks (module index). Includes stuff like request and response objects. From the web site: "The future of these pieces is to split them into independent packages, and refactor the internal Paste dependencies to rely instead on WebOb". If you're considering using components from paste core, I suggest you look at the spin-offs instead, like WebOb.
Paste Deploy: a system for loading and configuring WSGI applications and servers (module index). Basically some stuff to read a config file and create a WSGI app as specified in the file.
Paste Script: A framework for defining commands. It comes with a few commands out of the box, like paster serve (loads and serves a WSGI application defined in a Paste Deploy config file) and paster create (creates directory layout for packages etc). The best intro to paste script I found is http://pythonpaste.org/script/developer.html
Here's the source for the paster serve command: serve.py.
And paster create: create_distro.py.
PasteScript (and its companion PasteDeploy) are tools for running Python code using 'entry points'. Basically, a python library can specify in metadata that it knows how to create a certain kind of Python project, or perform certain operations on those projects. paster is a commandline tool that looks up the appropriate code for the operation you requested. It's a very general kind of problem; if you're familiar with Ruby at all, the equivalent might be 'rake'.
In particular, PasteDeploy is a configuration format to serve Python webapps using paster. Both PasteScript and PasteDeploy are important for the Pylons web framework.