In this article by Jack Stouffer, the author of the book Mastering Flask, you will learn how to deploy and host your application on the different options available, and the advantages and disadvantages related to them.
The most common way to deploy any web app is to run it on a server that you have control over. Control in this case means access to the terminal on the server with an administrator account. This type of deployment gives you the most amount of freedom out of the other choices as it allows you to install any program or tool you wish. This is in contrast to other hosting solutions where the web server and database are chosen for you. This type of deployment also happens to be the least expensive option.
The downside to this freedom is that you take the responsibility of keeping the server up, backing up user data, keeping the software on the server up to date to avoid security issues, and so on. Entire books have been written on good server management, so if this is not a responsibility that you believe you or your company can handle, it would be best if you choose one of the other deployment options.
This section will be based on a Debian Linux-based server, as Linux is far and away the most popular OS for running web servers, and Debian is the most popular Linux distro (a particular combination of software and the Linux kernel released as a package). Any OS with Bash and a program called SSH (which will be introduced in the next section) will work for this article, the only differences will be the command-line programs to install software on the server.
(For more resources related to this topic, see here.)
Each of these web servers will use a protocol named Web Server Gateway Interface (WSGI), which is a standard designed to allow Python web applications to easily communicate with web servers. We will never directly work with WSGI. However, most of the web server interfaces we will be using will have WSGI in their name, and it can be confusing if you don’t know what the name is.
Pushing code to your server with fabric
To automate the process of setting up and pushing our application code to the server, we will use a Python tool called fabric. Fabric is a command-line program that reads and executes Python scripts on remote servers using a tool called SSH. SSH is a protocol that allows a user of one computer to remotely log in to another computer and execute commands on the command line, provided that the user has an account on the remote machine.
To install fabric, we will use pip:
$ pip install fabricFabric commands are collections of command-line programs to be run on the remote machine’s shell, in this case, Bash. We are going to make three different commands: one to run our unit tests, one to set up a brand new server to our specifications, and one to have the server update its copy of the application code with git. We will store these commands in a new file at the root of our project directory called fabfile.py.
As it’s the easiest to create, let’s make the test command first:
from fabric.api import local
def test():
local('python -m unittest discover')To run this function from the command line, we can use fabric’s command-line interface by passing the name of the command to run:
$ fab test
[localhost] local: python -m unittest discover
.....
---------------------------------------------------------------------
Ran 5 tests in 6.028s
OK
Fabric has three main commands: local, run, and sudo. The local function, as seen in the preceding function, runs commands on the local computer. The run and sudo functions run commands on a remote machine, but sudo runs commands as an administrator. All of these functions notify fabric if the command ran successfully or not. If a command didn’t run successfully, meaning that our tests failed in this case, any other commands in the function will not be run. This is useful for our commands because it allows us to force ourselves not to push any code to the server that does not pass our tests.
Now we need to create the command to set up a new server from scratch. What this command will do is install the software our production environment needs as well as downloads the code from our centralized git repository. It will also create a new user that will act as the runner of the web server as well as the owner of the code repository.
Do not run your webserver or have your code deployed by the root user. This opens your application to a whole host of security vulnerabilities.
This command will differ based on your operating system, and we will be adding to this command in the rest of the article based on what server you choose:
from fabric.api import env, local, run, sudo, cd
env.hosts = ['deploy@[your IP]']
def upgrade_libs():
sudo("apt-get update")
sudo("apt-get upgrade")
def setup():
test()
upgrade_libs()
# necessary to install many Python libraries
sudo("apt-get install -y build-essential")
sudo("apt-get install -y git")
sudo("apt-get install -y python")
sudo("apt-get install -y python-pip")
# necessary to install many Python libraries
sudo("apt-get install -y python-all-dev")
run("useradd -d /home/deploy/ deploy")
run("gpasswd -a deploy sudo")
# allows Python packages to be installed by the deploy user
sudo("chown -R deploy /usr/local/")
sudo("chown -R deploy /usr/lib/python2.7/")
run("git config --global credential.helper store")
with cd("/home/deploy/"):
run("git clone [your repo URL]")
with cd('/home/deploy/webapp'):
run("pip install -r requirements.txt")
run("python manage.py createdb")There are two new fabric features in this script. One is the env.hosts assignment, which tells fabric the user and IP address of the machine it should be logging in to. Second, there is the cd function used in conjunction with the with keyword, which executes any functions in the context of that directory instead of the home directory of the deploy user. The line that modifies the git configuration is there to tell git to remember your repository’s username and password, so you do not have to enter it every time you wish to push code to the server. Also, before the server is set up, we make sure to update the server’s software to keep the server up to date.
Finally, we have the function to push our new code to the server. In time, this command will also restart the web server and reload any configuration files that come from our code. But this depends on the server you choose, so this is filled out in the subsequent sections:
def deploy():
test()
upgrade_libs()
with cd('/home/deploy/webapp'):
run("git pull")
run("pip install -r requirements.txt")
So, if we were to begin working on a new server, all we would need to do to set it up is to run the following commands:
$ fabric setup
$ fabric deployRunning your web server with supervisor
Now that we have automated our updating process, we need some program on the server to make sure that our web server, and database if you aren’t using SQLite, is running. To do this, we will use a simple program called supervisor. All that supervisor does is automatically run command-line programs in background processes and allows you to see the status of running programs. Supervisor also monitors all of the processes its running, and if the process dies, it tries to restart it.
To install supervisor, we need to add it to the setup command in our fabfile.py:
def setup():
…
sudo("apt-get install -y supervisor")
To tell supervisor what to do, we need to create a configuration file and then copy it to the /etc/supervisor/conf.d/ directory of our server during the deploy fabric command. Supervisor will load all of the files in this directory when it starts and attempt to run them. In a new file in the root of our project directory named supervisor.conf, add the following:
[program:webapp]
command=
directory=/home/deploy/webapp
user=deploy
[program:rabbitmq]
command=rabbitmq-server
user=deploy
[program:celery]
command=celery worker -A celery_runner
directory=/home/deploy/webapp
user=deploy
This is the bare minimum configuration needed to get a web server up and running. But, supervisor has a lot more configuration options. To view all of the customizations, go to the supervisor documentation at http://supervisord.org/.
This configuration tells supervisor to run a command in the context of /home/deploy/webapp under the deploy user. The right hand of the command value is empty because it depends on what server you are running and will be filled in for each section.
Now we need to add a sudo call in the deploy command to copy this configuration file to the /etc/supervisor/conf.d/ directory:
def deploy():
…
with cd('/home/deploy/webapp'):
…
sudo("cp supervisord.conf /etc/supervisor/conf.d/webapp.conf")
sudo('service supervisor restart')
A lot of projects just create the files on the server and forget about them, but having the configuration file stored in our git repository and copied on every deployment gives several advantages. First, this means that it easy to revert changes if something goes wrong using git. Second, it means that we don’t have to log in to our server in order to make changes to the files.
Don’t use the Flask development server in production. Not only it fails to handle concurrent connections, but it also allows arbitrary Python code to be run on your server.
Gevent
The simplest option to get a web server up and running is to use a Python library called gevent to host your application. Gevent is a Python library that adds an alternative way of doing concurrent programming outside of the Python threading library called coroutines. Gevent has an interface for running WSGI applications that is both simple and has good performance. A simple gevent server can easily handle hundreds of concurrent users, which is more in number than 99 percent of websites on the Internet will ever have. The downside to this option is that its simplicity means a lack of configuration options. There is no way, for example, to add rate limiting to the server or to add HTTPS traffic. This deployment option is purely for sites that you don’t expect to receive a huge amount of traffic. Remember YAGNI (short for You Aren’t Gonna Need It); only upgrade to a different web server if you really need to.
Coroutines are a bit outside of the scope of this book, so a good explanation can be found at https://en.wikipedia.org/wiki/Coroutine.
To install gevent, we will use pip:
$ pip install geventIn a new file in the root of the project directory named gserver.py, add the following:
from gevent.wsgi import WSGIServer
from webapp import create_app
app = create_app('webapp.config.ProdConfig')
server = WSGIServer(('', 80), app)
server.serve_forever()
To run the server with supervisor, just change the command value to the following:
[program:webapp]
command=python gserver.py
directory=/home/deploy/webapp
user=deploy
Now when you deploy, gevent will be automatically installed for you by running your requirements.txt on every deployment, that is, if you are properly pip freeze–ing after every new dependency is added.
Tornado
Tornado is another very simple way to deploy WSGI apps purely with Python. Tornado is a web server that is designed to handle thousands of simultaneous connections. If your application needs real-time data, Tornado also supports websockets for continuous, long-lived connections to the server.
Do not use Tornado in production on a Windows server. The Windows version of Tornado is not only much slower, but it is considered beta quality software.
To use Tornado with our application, we will use Tornado’s WSGIContainer in order to wrap the application object to make it Tornado compatible. Then, Tornado will start to listen on port 80 for requests until the process is terminated. In a new file named tserver.py, add the following:
from tornado.wsgi import WSGIContainer
from tornado.httpserver import HTTPServer
from tornado.ioloop import IOLoop
from webapp import create_app
app = WSGIContainer(create_app("webapp.config.ProdConfig"))
http_server = HTTPServer(app)
http_server.listen(80)
IOLoop.instance().start()To run the Tornado with supervisor, just change the command value to the following:
[program:webapp]
command=python tserver.py
directory=/home/deploy/webapp
user=deploy
Nginx and uWSGI
If you need more performance or customization, the most popular way to deploy a Python web application is to use the web server Nginx as a frontend for the WSGI server uWSGI by using a reverse proxy. A reverse proxy is a program in networks that retrieves contents for a client from a server as if they returned from the proxy itself as shown in the following figure:
Nginx and uWSGI are used in this way because we get the power of the Nginx frontend while having the customization of uWSGI.
Nginx is a very powerful web server that became popular by providing the best combination of speed and customization. Nginx is consistently faster than other web severs, such as Apache httpd, and has native support for WSGI applications. The way it achieves this speed is several good architecture decisions as well as the decision early on that they were not going to try to cover a large amount of use cases like Apache does. Having a smaller feature set makes it much easier to maintain and optimize the code. From a programmer’s perspective, it is also much easier to configure Nginx, as there is no giant default configuration file (httpd.conf) that needs to be overridden with .htaccess files in each of your project directories. One downside is that Nginx has a much smaller community than Apache, so if you have an obscure problem, you are less likely to be able to find answers online. Also, it’s possible that a feature that most programmers are used to in Apache isn’t supported in Nginx.
uWSGI is a web server that supports several different types of server interfaces, including WSGI. uWSGI handles severing the application content as well as things such as load balancing traffic across several different processes and threads.
To install uWSGI, we will use pip in the following way:
$ pip install uwsgiIn order to run our application, uWSGI needs a file with an accessible WSGI application. In a new file named wsgi.py in the top level of the project directory, add the following:
from webapp import create_app
app = create_app("webapp.config.ProdConfig")
To test uWSGI, we can run it from the command line with the following:
$ uwsgi --socket 127.0.0.1:8080
--wsgi-file wsgi.py
--callable app
--processes 4
--threads 2
If you are running this on your server, you should be able to access port 8080 and see your app (if you don’t have a firewall that is).
What this command does is load the app object from the wsgi.py file and makes it accessible from localhost on port 8080. It also spawns four different processes with two threads each, which are automatically load balanced by a master process. This amount of processes is the overkill for the vast, vast majority of websites. To start off, use a single process with two threads and scale up from there.
Instead of adding all of the configuration options on the command line, we can create a text file to hold our configuration, which brings the same benefits for configuration that were listed in the section on supervisor. In a new file in the root of the project directory named uwsgi.ini, add the following:
[uwsgi]
socket = 127.0.0.1:8080
wsgi-file = wsgi.py
callable = app
processes = 4
threads = 2
uWSGI supports hundreds of configuration options as well as several official and unofficial plugins. To leverage the full power of uWSGI, you can explore the documentation at http://uwsgi-docs.readthedocs.org/.
Let’s run the server now from supervisor:
[program:webapp]
command=uwsgi uwsgi.ini
directory=/home/deploy/webapp
user=deploy
We also need to install Nginx during the setup function:
def setup():
…
sudo("apt-get install -y nginx")
Because we are installing Nginx from the OS’s package manager, the OS will handle running Nginx for us.
At the time of writing, the Nginx version in the official Debian package manager is several years old. To install the most recent version, follow the instructions here: http://wiki.nginx.org/Install.
Next, we need to create an Nginx configuration file and then copy it to the /etc/nginx/sites-available/ directory when we push the code. In a new file in the root of the project directory named nginx.conf, add the following
server {
listen 80;
server_name your_domain_name;
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:8080;
}
location /static {
alias /home/deploy/webapp/webapp/static;
}
}
What this configuration file does is tell Nginx to listen for incoming requests on port 80 and forward all requests to the WSGI application that is listening on port 8080. Also, it makes an exception for any requests for static files and instead sends those requests directly to the file system. Bypassing uWSGI for static files gives a great performance boost, as Nginx is really good at serving static files quickly.
Finally, in the fabfile.py file:
def deploy():
…
with cd('/home/deploy/webapp'):
…
sudo("cp nginx.conf "
"/etc/nginx/sites-available/[your_domain]")
sudo("ln -sf /etc/nginx/sites-available/your_domain "
"/etc/nginx/sites-enabled/[your_domain]")
sudo("service nginx restart")
Apache and uWSGI
Using Apache httpd with uWSGI has mostly the same setup. First off, we need an apache configuration file in a new file in the root of our project directory named apache.conf:
<VirtualHost *:80>
<Location />
ProxyPass / uwsgi://127.0.0.1:8080/
</Location>
</VirtualHost>
This file just tells Apache to pass all requests on port 80 to the uWSGI web server listening on port 8080. But, this functionality requires an extra Apache plugin from uWSGI called mod proxy uWSGI. We can install this as well as Apache in the set command:
def setup():
…
sudo("apt-get install -y apache2")
sudo("apt-get install -y libapache2-mod-proxy-uwsgi")
Finally, in the deploy command, we need to copy our Apache configuration file into Apache’s configuration directory.
def deploy():
…
with cd('/home/deploy/webapp'):
…
sudo("cp apache.conf "
"/etc/apache2/sites-available/[your_domain]")
sudo("ln -sf /etc/apache2/sites-available/[your_domain] "
"/etc/apache2/sites-enabled/[your_domain]")
sudo("service apache2 restart")
Summary
In this article you learnt that there are many different options to hosting your application, each having their own pros and cons. Deciding on one depends on the amount of time and money you are willing to spend as well as the total number of users you expect.
Resources for Article:
Further resources on this subject:
- Handling sessions and users[article]
- Snap – The Code Snippet Sharing Application[article]
- Man, Do I Like Templates! [article]
from fabric.api import local
def test():
local(‘python -m unittest discover’)
