I've followed the excellent tutorial https://www.digitalocean.com/community/tutorials/how-to-serve-django-applications-with-apache-and-mod_wsgi-on-centos-7 to install Apache, mod_wsgi, and Django. All such tutorials leave the location of the python virtual environment and Django project up to the developer, but I'm wondering if there is any Best Practice for selecting an appropriate location. For example, the tutorial suggests creating a virtual environment in the user's home directory:
mkdir ~/myproject
cd ~/myproject
virtualenv myprojectenv
and
WSGIDaemonProcess myproject python-path=/home/user/myproject:/home/user/myproject/myprojectenv/lib/python2.7/site-packages
(Python 3.4 wisely discarded virtualenv, replacing it with the automatically-created version-specific pyvenv-3.4.)
Now that Apache successfully displays the Django 1.8 startup page ("Get to work!"), I want to put the project in a location more suitable to a production environment than my home directory. Options include:
1) The Apache ServerRoot /etc/httpd - that was my first thought, except that /etc is (should be?) used just for configuration information, not installed software
2) Leave it in my home directory /home/username/myproject - undesirable because I'd rather not give permission for httpd to read my home directory, and because I'd rather not be able to accidentally mess up the project when logged in as me.
3) Create a project directory in /home, e.g. /home/myproject or /home/web/myproject, without creating a user account for myproject or web. That's my current preferred option, but it seems a bit strange to have directories in /home not owned by a user. All files in the project would be owned by root:apache, with read-only permission for the apache daemon and no permissions for world.
4) Elsewhere, such as /bin, /lib, or /lib64, none of which seem particularly suitable.
5) DocumentRoot /var/www - DEFINITELY NOT!
So are there any best practice conventions for where to set up a production Django project on a Linux server?
By Filesystem Hierarchy Standard the site specific services running on the server should go under /srv.
In your case this could be /srv/django/myproject.
Related
include(
# the project different envs settings
optional('envs/devel/*.py'),
optional('envs/production/*.py'),
optional('envs/staging/*.py'),
# for any local settings
optional('local_settings.py'),
optional('path.py'),
)
What should be the folder structure I follow to build Django web application, I did not found any repo on github in which contains files that are made according to the environments. As i am moving from php to python i did not found how to exactly define the constants in python so that the value of the constants will not change anywhere.
print("currently i am using django-split-settings to include files")
when using django you do not do this. rather in the settings.py file. you check whether the debug flag is true or false i.e. whether the project is in production or not. to change the settings for development/deployment.
hosting on github
when you host it on github any thing is fine as long as you add a requirements.txt
to allow you to install the requirements on another machine. its a good rule of thumb to not use virtualenvs on different machines so it is rare to see them on github repos.
I have found quite a few guides for running Flask on Linux/Unix with various technologies (nginx/apache/uWSGI/gunicorn/etc.) but all of them appear to work best on Linux, and only incidentally work on Windows, or not work at all on Windows. Are there any recommended ways to serve Flask apps in production in a Windows environment?
I have done this a few times. It can be done with only moderate hits to performance. You will want to leverage IIS and FastCGI.
Here is a link to a blog post detailing a method: https://medium.com/#bilalbayasut/deploying-python-web-app-flask-in-windows-server-iis-using-fastcgi-6c1873ae0ad8
Here is a link to a SO post detailing the same method: https://stackoverflow.com/a/22107980/8508792
and the contents, just in case the post gets taken down...
High Level Overview
HTTP -> IIS -> ISAPI -> FastCGI -> WSGI (Flask application)
Setup Steps
Step 1: Install Required Binaries
Install Python (2.7 or 3.x -- I used 3.3)
Install pip-Win (I used version 1.6)
Install pywin32 (I used version 218)
Install the IIS FastCGI extension with fcgisetup 1.5
Step 2: Install Optional Binary Packages
I installed pyodbc using the installer .exe from this site. Installing from source (e.g. pip, for installing into a virtual environment) requires a C/C++ compiler.
Step 3: Get a Copy of wfastcgi.py
Choose a version that will work for you, preferably one that supports Python 3.3 (I used David Ebbo's). You may want the "official" version from here.
Install the wfastcgi.py script into C:\Inetpub\wwwroot and make sure the account that will serve your application ("Network Service" by default) has read access to it.
Step 4: Install virtualenv Into the System site-packages
C:\Python33\Scripts\pip.exe install virtualenv
(if you are using Python 3.3 and installed everything in the default location)
Step 5: Install Your Flask Application
You may install the application just about anywhere on the system. You may want to install it under C:\Inetpub. For this tutorial, we'll call the root folder of your application install %APPROOT%. (Don't put quotation marks in the environment variable.)
Make sure that the account that will serve your application ("Network Service" by default) has read access to all of the script files. This command:
cacls "%APPROOT%" /S:"D:PAI(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;NS)(A;OICI;FA;;;SY)"
will give your application directory the following permissions:
BUILTIN\Administrators: Full control of this folder, subfolders, and files
CREATOR OWNER: Full control for subfolders and files only
NT AUTHORITY\NETWORK SERVICE: Read permissions for this folder, subfolders, and files
NT AUTHORITY\SYSTEM: Full control of this folder, subfolders, and files
Add any local configuration necessary (my application uses a local.cnf file that is ignored by the version control system) -- e.g. database URLs.
Make sure your application contains a Web.config file in %APPROOT% -- see the section below for information on the file format.
Step 6: Create a virtualenv For Your Application
C:\Python33\Scripts\virtualenv.exe --system-site-packages "%APPROOT%\env"
(Pick a name other than env if your application already uses that directory.)
Step 7: Install The Packages Required By Your Application to the virtualenv
cd "%APPROOT%"
env\Scripts\activate
pip install -r Packages
(My project keeps the requirements spec in a file named Packages.)
Step 8: Create a Web Site Or Virtual Directory For Your Application
Use inetmgr.msc (Start -> Run…, then enter inetmgr in the edit box and press ENTER) to launch Internet Information Services (IIS) Manager. Make sure to set the local path for the node (Web Site or Virtual Directory) you create to the root folder of your Flask application. wfastcgi.py uses the local path to identify the Flask application to handle the requests.
Give both Read and Script (Run Scripts) permissions for the node.
Step 9: Configure fcgiext.ini
This file is located in the same directory as the fcgiext.dll installed in Step 1 (by default, %SYSTEMROOT%\system32\inetsrv).
In configuring this file, you need several parameters:
{site id}: the numeric Site ID you can find in the detail (right-hand) pane of Internet Information Services (IIS) Manager when “Web Sites” is selected from the tree on the left side of the window.
{application name}: the name of the section within fcgiext.ini that provides the parameters for the FastCGI (ISAPI) handler. You choose this value -- select something that represents your application.
{path to app}: for a Virtual Directory, the URL path within the Web Site to the Virtual Directory to be handled.
{approot}: the path to the root directory of your application.
Use those parameters to:
Map the FastCGI requests to a handling section:
For a whole Web Site, add *:{site id}={application name} to the [Types] section.
For a Virtual Directory, add *:/lm/w3svc/{site id}/root/{path to app}={application name} to the [Types] section.
Add a handling section ([{application name}]) with parameters for this application (full reference):
ExePath={approot}\env\python.exe
Arguments=C:\Inetpub\wwwroot\wfastcgi.py (or wherever the wfastcgi.py adapter script is installed)
EnvironmentVars=ENV_VAR1:value,ENV_VAR2:value,etc. (see the full reference for quoting rules). This is a good place to set your WSGI_LOG environment variable -- make sure the account serving the site (“Network Service” by default) has write permissions for the file and (if the file doesn’t exist) permission to add a file to the containing directory.
Step 10: Configure FastCGI Handling for the Target URLs
Using Internet Information Services (IIS) Manager, select “Properties...” from the context (right-click) menu of the node (Web Site or Virtual Directory) to be served by your Flask application and:
In the “Home Directory” tab (Web Site) or “Virtual Directory” tab (Virtual Directory), click the “Configuration..." button.
In the “Wildcard application maps” section, use the “Insert..." button to add a wildcard mapping:
The executable is the FastCGI extension DLL installed in Step 1. Its default location is %SYSTEMROOT%\system32\inetsrv\fcgiext.dll.
Make sure “Verify that file exists” is unchecked. Flask applications do their own routing that doesn’t necessarily have anything to do with the files on the disk.
Web.config
This file is (in this setup) read by wfastcgi.py, not by IIS.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<applicationSettings>
<add key=“PYTHONPATH” value=“”/>
<add key=“WSGI_HANDLER” value=“module.application”/>
</applicationSettings>
</configuration>
<add> elements add environment variables (os.environ in Python).
WSGI_HANDLER must be specified -- it tells wfastcgi.py how to locate the WSGI application object. If the value ends in "()", wfastcgi.py will call the named object, expecting it to return a WSGI application object.
PYTHONPATH is handled specially -- wfastcgi.py performs (environment) variable expansion (using the Windows standard %VAR% notation) on the value of PYTHONPATH, then splits the result at semicolons and appends the entries to sys.path before invoking the WSGI application. Because wfastcgi.py changes the current directory to the path specified as the local path of the Web Site or Virtual Directory before importing the module containing the WSGI application object, including an empty string in the PYTHONPATH will cause the search to include your Flask application directory as a starting point. You can also set PYTHONPATH in fcgiext.ini (in which case it is included in sys.path by the interpreter and then again by wfastcgi.py).
WSGI_RESTART_FILE_REGEX gives a Python regular expression used to filter file-change notifications for paths that should trigger FastCGI handler process restarts. Set this to trigger when source files or configuration files change. I use (?i).*\.(py|cnf|config)$.
WSGI_LOG may be set here, but I think it is better set in fcgiext.ini.
For IIS 7
Some things with FastCGI changed dramatically with IIS 7. Beginning with this version, FastCGI has support directly through IIS and is not configured through an extension (i.e. Step 1.4 is not necessary and fcgiext.ini does not control FastCGI behavior for IIS 7+ and there is no need to create/edit it). Instead, make sure that CGI is enable under Internet Information Services in Control Panel > Programs and Features > Turn Windows Features on or off.
Web.config
IIS 7 is the first version of IIS to read configuration settings related to FastCGI from the Web.config file. Your Web.config file will need to contain, within the <configuration> element, a <system.webServer> element containing a <handlers> element containing an <add> element with the attributes:
path: *
verb: *
modules: FastCgiModule
resourceType: Unspecified
requireAccess: Script
scriptProcessor: the tricky one
The scriptProcessor Attribute
This attribute of the <add> element must contain the full path to the Python interpreter .exe file you want to use (the one in the Scripts subfolder of your Python virtualenv) followed by a | and then the full path to the wfastcgi.py file you are using. As these paths are dependent on the setup of the machine on which your app is running, you may want to have this attribute set as part of your deployment process.
IIS Server-wide Set Up
In inetmgr, click on the server node in the tree and then choose FastCGI Settings from the center pane. A list of executable/argument pairs will come up.
Add an entry for the full paths to your python.exe and the wfastcgi.py you are using. Both should be given the same way they show up in the <handlers>/<add> element in your Web.config.
Make sure to set up the PYTHONPATH environment variable in the new FastCGI application entry to include the root of your application codebase. The advice about adding an empty PYTHONPATH entry in the <applicationSettings> of your Web.config may not apply to this version of IIS.
You have hit the nail on the head there. Installing on Windows is kind of like trying to fit square pegs in round holes. Apache and mod_wsgi would probably be the best fit, but the whole experience is much smoother and straightforward (with pip, apt-get etc.) on a Linux box. Would a Linux VM running on the Windows server be a suitable compromise?
One potential pathway, though I foresee it to be very complicated, is having your flask app running in windows subsystem of linux.
There's existing tutorials on how to make calls to powershell scripts from the subsystem, e.g.,: https://www.raymondcamden.com/2017/09/25/calling-a-powershell-script-from-wsl
I am successfully using the simple Twisted Web server on Windows for Flask web sites.
Are others also successfully using Twisted on Windows, to validate that configuration?
new_app.py
if name == "main":
reactor_args = {}
def run_twisted_wsgi():
from twisted.internet import reactor
from twisted.web.server import Site
from twisted.web.wsgi import WSGIResource
resource = WSGIResource(reactor, reactor.getThreadPool(), app)
site = Site(resource)
reactor.listenTCP(5000, site)
reactor.run(**reactor_args)
if app.debug:
# Disable twisted signal handlers in development only.
reactor_args['installSignalHandlers'] = 0
# Turn on auto reload.
import werkzeug.serving
run_twisted_wsgi = werkzeug.serving.run_with_reloader(run_twisted_wsgi)
run_twisted_wsgi()
old_app.py
if name == "main":
app.run()
I recommend the following approach:
IIS
... with the IIS CGI/FastCGI module enabled
... using the wfastcgi python module to host a Python WSGI web application under IIS FastCGI
When correctly set up, deploying a Python web app on IIS is very easy, and can be done without clicking around in IIS admin, simply be editing the site/apps web.config file.
Documentation: https://pypi.org/project/wfastcgi/
Source code: https://github.com/microsoft/PTVS/tree/master/Python/Product/WFastCgi
I'm just about getting started on deploying my first live Django website, and I'm wondering how to set the Ubuntu server file permissions in the optimal way for security, whilst still granting the permissions required.
Firstly a question of directories: I'm currently storing the site in ~/www/mysite.com/{Django apps}, but have often seen people using /var/www/... or /srv/www; is there any reason picking one of these directories is better than the other? or any reason why keeping the site in my home dir is a bad idea?
Secondly, the permissions of the dir and files themselves. I'm serving using apache with mod_wsgi, and have the file WSGIScriptAlias / ~/www/mysite.com/mainapp/wsgi.py file. Apache runs as www-data user. For optimal security who should own the wsgi.py file, and what permissions should I grant it and its containing dir?
Similarly, for the www, www/mysite.com, and www/mysite.com/someapp directories? What are the minimal permissions that are needed for the dirs and files?
Currently I am using 755 and 644 for dir and files respecitvely, which works well enough which allows the site to function, but I wonder if it is optimal/too liberal. My Ubuntu user is the owner of most files, and www-data owns the sqlite dbs.
In regards to serving the application from your home directory, this is primarily preference based. However, deployment decisions may be made depending on the situation. For example, if you have multiple users making use of this server to host their website, then you would likely have the files served from their home directories. From a system administrator's perspective that is deploying the applications; you may want them all accessible from /var/www... so they are easier to locate.
The permissions you set for serving the files seem fine, however they may need to run as different users... depending on the number of people using this machine. For example, lets say you have one other application running on the server and that both applications run as www-data. If the www-data user has read permissions of Django's config file, then the other user could deploy a script that can read your database credentials.
Can anyone help me get a Flask application running on IIS 6? I have tried to use isapi-wsgi, but when I visit the Virtual Directory address I get a page that says "The specified module could not be found." Are there other options for this?
Below is the Python script I wrote for isapi-wsgi. The Virtual Directory was made and everything looked ok in IIS Manager, but the site did not work.
from wof import app
import os
app.secret_key=os.urandom(24)
import isapi_wsgi
def __ExtensionFactory__():
return isapi_wsgi.ISAPISimpleHandler(app)
if __name__ == '__main__':
from isapi.install import *
params = ISAPIParameters()
sm = [ScriptMapParams(Extension="*", Flags=0)]
vd = VirtualDirParameters(Name="WOFPy_Sondes", Description="ISAPI-WSGI for WOFPY Sondes test", ScriptMaps=sm, ScriptMapUpdate="replace")
params.VirtualDirs = [vd]
HandleCommandLine(params)
High Level Overview
HTTP -> IIS -> ISAPI -> FastCGI -> WSGI (Flask application)
Setup Steps
Step 1: Install Required Binaries
Install Python (2.7 or 3.x -- I used 3.3)
Install pip-Win (I used version 1.6)
Install pywin32 (I used version 218)
Install the IIS FastCGI extension with fcgisetup 1.5
Step 2: Install Optional Binary Packages
I installed pyodbc using the installer .exe from this site. Installing from source (e.g. pip, for installing into a virtual environment) requires a C/C++ compiler.
Step 3: Get a Copy of wfastcgi.py
Choose a version that will work for you, preferably one that supports Python 3.3 (I used David Ebbo's). You may want the "official" version from here.
Install the wfastcgi.py script into C:\Inetpub\wwwroot and make sure the account that will serve your application ("Network Service" by default) has read access to it.
Step 4: Install virtualenv Into the System site-packages
C:\Python33\Scripts\pip.exe install virtualenv
(if you are using Python 3.3 and installed everything in the default location)
Step 5: Install Your Flask Application
You may install the application just about anywhere on the system. You may want to install it under C:\Inetpub. For this tutorial, we'll call the root folder of your application install %APPROOT%. (Don't put quotation marks in the environment variable.)
Make sure that the account that will serve your application ("Network Service" by default) has read access to all of the script files. This command:
cacls "%APPROOT%" /S:"D:PAI(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;NS)(A;OICI;FA;;;SY)"
will give your application directory the following permissions:
BUILTIN\Administrators: Full control of this folder, subfolders, and files
CREATOR OWNER: Full control for subfolders and files only
NT AUTHORITY\NETWORK SERVICE: Read permissions for this folder, subfolders, and files
NT AUTHORITY\SYSTEM: Full control of this folder, subfolders, and files
Add any local configuration necessary (my application uses a local.cnf file that is ignored by the version control system) -- e.g. database URLs.
Make sure your application contains a Web.config file in %APPROOT% -- see the section below for information on the file format.
Step 6: Create a virtualenv For Your Application
C:\Python33\Scripts\virtualenv.exe --system-site-packages "%APPROOT%\env"
(Pick a name other than env if your application already uses that directory.)
Step 7: Install The Packages Required By Your Application to the virtualenv
cd "%APPROOT%"
env\Scripts\activate
pip install -r Packages
(My project keeps the requirements spec in a file named Packages.)
Step 8: Create a Web Site Or Virtual Directory For Your Application
Use inetmgr.msc (Start -> Run…, then enter inetmgr in the edit box and press ENTER) to launch Internet Information Services (IIS) Manager. Make sure to set the local path for the node (Web Site or Virtual Directory) you create to the root folder of your Flask application. wfastcgi.py uses the local path to identify the Flask application to handle the requests.
Give both Read and Script (Run Scripts) permissions for the node.
Step 9: Configure fcgiext.ini
This file is located in the same directory as the fcgiext.dll installed in Step 1 (by default, %SYSTEMROOT%\system32\inetsrv).
In configuring this file, you need several parameters:
{site id}: the numeric Site ID you can find in the detail (right-hand) pane of Internet Information Services (IIS) Manager when “Web Sites” is selected from the tree on the left side of the window.
{application name}: the name of the section within fcgiext.ini that provides the parameters for the FastCGI (ISAPI) handler. You choose this value -- select something that represents your application.
{path to app}: for a Virtual Directory, the URL path within the Web Site to the Virtual Directory to be handled.
{approot}: the path to the root directory of your application.
Use those parameters to:
Map the FastCGI requests to a handling section:
For a whole Web Site, add *:{site id}={application name} to the [Types] section.
For a Virtual Directory, add *:/lm/w3svc/{site id}/root/{path to app}={application name} to the [Types] section.
Add a handling section ([{application name}]) with parameters for this application (full reference):
ExePath={approot}\env\python.exe
Arguments=C:\Inetpub\wwwroot\wfastcgi.py (or wherever the wfastcgi.py adapter script is installed)
EnvironmentVars=ENV_VAR1:value,ENV_VAR2:value,etc. (see the full reference for quoting rules). This is a good place to set your WSGI_LOG environment variable -- make sure the account serving the site (“Network Service” by default) has write permissions for the file and (if the file doesn’t exist) permission to add a file to the containing directory.
Step 10: Configure FastCGI Handling for the Target URLs
Using Internet Information Services (IIS) Manager, select “Properties...” from the context (right-click) menu of the node (Web Site or Virtual Directory) to be served by your Flask application and:
In the “Home Directory” tab (Web Site) or “Virtual Directory” tab (Virtual Directory), click the “Configuration..." button.
In the “Wildcard application maps” section, use the “Insert..." button to add a wildcard mapping:
The executable is the FastCGI extension DLL installed in Step 1. Its default location is %SYSTEMROOT%\system32\inetsrv\fcgiext.dll.
Make sure “Verify that file exists” is unchecked. Flask applications do their own routing that doesn’t necessarily have anything to do with the files on the disk.
Web.config
This file is (in this setup) read by wfastcgi.py, not by IIS.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<applicationSettings>
<add key=“PYTHONPATH” value=“”/>
<add key=“WSGI_HANDLER” value=“module.application”/>
</applicationSettings>
</configuration>
<add> elements add environment variables (os.environ in Python).
WSGI_HANDLER must be specified -- it tells wfastcgi.py how to locate the WSGI application object. If the value ends in "()", wfastcgi.py will call the named object, expecting it to return a WSGI application object.
PYTHONPATH is handled specially -- wfastcgi.py performs (environment) variable expansion (using the Windows standard %VAR% notation) on the value of PYTHONPATH, then splits the result at semicolons and appends the entries to sys.path before invoking the WSGI application. Because wfastcgi.py changes the current directory to the path specified as the local path of the Web Site or Virtual Directory before importing the module containing the WSGI application object, including an empty string in the PYTHONPATH will cause the search to include your Flask application directory as a starting point. You can also set PYTHONPATH in fcgiext.ini (in which case it is included in sys.path by the interpreter and then again by wfastcgi.py).
WSGI_RESTART_FILE_REGEX gives a Python regular expression used to filter file-change notifications for paths that should trigger FastCGI handler process restarts. Set this to trigger when source files or configuration files change. I use (?i).*\.(py|cnf|config)$.
WSGI_LOG may be set here, but I think it is better set in fcgiext.ini.
For IIS 7
Some things with FastCGI changed dramatically with IIS 7. Beginning with this version, FastCGI has support directly through IIS and is not configured through an extension (i.e. Step 1.4 is not necessary and fcgiext.ini does not control FastCGI behavior for IIS 7+ and there is no need to create/edit it). Instead, make sure that CGI is enable under Internet Information Services in Control Panel > Programs and Features > Turn Windows Features on or off.
Web.config
IIS 7 is the first version of IIS to read configuration settings related to FastCGI from the Web.config file. Your Web.config file will need to contain, within the <configuration> element, a <system.webServer> element containing a <handlers> element containing an <add> element with the attributes:
path: *
verb: *
modules: FastCgiModule
resourceType: Unspecified
requireAccess: Script
scriptProcessor: the tricky one
The scriptProcessor Attribute
This attribute of the <add> element must contain the full path to the Python interpreter .exe file you want to use (the one in the Scripts subfolder of your Python virtualenv) followed by a | and then the full path to the wfastcgi.py file you are using. As these paths are dependent on the setup of the machine on which your app is running, you may want to have this attribute set as part of your deployment process.
IIS Server-wide Set Up
In inetmgr, click on the server node in the tree and then choose FastCGI Settings from the center pane. A list of executable/argument pairs will come up.
Add an entry for the full paths to your python.exe and the wfastcgi.py you are using. Both should be given the same way they show up in the <handlers>/<add> element in your Web.config.
Make sure to set up the PYTHONPATH environment variable in the new FastCGI application entry to include the root of your application codebase. The advice about adding an empty PYTHONPATH entry in the <applicationSettings> of your Web.config may not apply to this version of IIS.
Check out Django's page on the subject. It helped me set up a working Django project, but it shouldn't be that different for a Flask app.
http://code.djangoproject.com/wiki/DjangoOnWindowsWithIISAndSQLServer
I never use IIS, but IIS supports CGI gateway, therefore you should be able to adapt CGI with WSGI.
IIS <--> CGI <--> WSGI
To run a WSGI as a CGI script, you can use the CGIHandler in Python standard library.
I am trying to create my first site in Django and as I'm looking for example apps out there to draw inspiration from, I constantly stumble upon a term called "reusable apps".
I understand the concept of an app that is reusable easy enough, but the means of reusing an app in Django are quite lost for me. Few questions that are bugging me in the whole business are:
What is the preferred way to re-use an existing Django app? Where do I put it and how do I reference it?
From what I understand, the recommendation is to put it on your "PYTHONPATH", but that breaks as soon as I need to deploy my app to a remote location that I have limited access to (e.g. on a hosting service).
So, if I develop my site on my local computer and intend to deploy it on an ISP where I only have ftp access, how do I re-use 3rd party Django apps so that if I deploy my site, the site keeps working (e.g. the only thing I can count on is that the service provider has Python 2.5 and Django 1.x installed)?
How do I organize my Django project so that I could easily deploy it along with all of the reusable apps I want to use?
In general, the only thing required to use a reusable app is to make sure it's on sys.path, so that you can import it from Python code. In most cases (if the author follows best practice), the reusable app tarball or bundle will contain a top-level directory with docs, a README, a setup.py, and then a subdirectory containing the actual app (see django-voting for an example; the app itself is in the "voting" subdirectory). This subdirectory is what needs to be placed in your Python path. Possible methods for doing that include:
running pip install appname, if the app has been uploaded to PyPI (these days most are)
installing the app with setup.py install (this has the same result as pip install appname, but requires that you first download and unpack the code yourself; pip will do that for you)
manually symlinking the code directory to your Python site-packages directory
using software like virtualenv to create a "virtual Python environment" that has its own site-packages directory, and then running setup.py install or pip install appname with that virtualenv active, or placing or symlinking the app in the virtualenv's site-packages (highly recommended over all the "global installation" options, if you value your future sanity)
placing the application in some directory where you intend to place various apps, and then adding that directory to the PYTHONPATH environment variable
You'll know you've got it in the right place if you can fire up a Python interpreter and "import voting" (for example) without getting an ImportError.
On a server where you have FTP access only, your only option is really the last one, and they have to set it up for you. If they claim to support Django they must provide some place where you can upload packages and they will be available for importing in Python. Without knowing details of your webhost, it's impossible to say how they structure that for you.
An old question, but here's what I do:
If you're using a version control system (VCS), I suggest putting all of the reusable apps and libraries (including django) that your software needs in the VCS. If you don't want to put them directly under your project root, you can modify settings.py to add their location to sys.path.
After that deployment is as simple as cloning or checking out the VCS repository to wherever you want to use it.
This has two added benefits:
Version mismatches; your software always uses the version that you tested it with, and not the version that was available at the time of deployment.
If multiple people work on the project, nobody else has to deal with installing the dependencies.
When it's time to update a component's version, update it in your VCS and then propagate the update to your deployments via it.