Chapter 12: Deploying Your App

We have done a lot of work, and I'm sure you are looking forward to sharing that work with the world. With the app in its current state, we will go through the process of setting up a server and deploying the app on a public address.

Essentially, what we will be doing is moving our data and code to a different computer and running the app in a similar way to what we have done so far. However, we need to set up a hosting account, a server, and a Web Server Gateway Interface (WSGI) in order for our app to be publicly available and visible. We will also need to establish a basic workflow for a development, deployment, and update cycle.

We will take a brief look at the Git source control management system, as well as do some basic Linux system administration. We will cover just enough to get our app online, and we won't even be scratching the surface of what can be done with those systems—I only mention them as a reference for further...

Technical requirements

We now need a Linux server connected to the internet, the data files, and our app's code. We will be installing Gunicorn (Green Unicorn, the WSGI) and nginx (the web server), as well as our app's Python packages as dependencies. We will install Dash and its main packages, Dash Bootstrap Components, pandas, and sklearn. An account on a source code management system such as Git will be needed, and we will be using GitHub as an example for this chapter.

Our development workflow so far has been to test certain functionality on JupyterLab and run it, and once it is working fine, we incorporate it to our app. This development workflow will not change. We will simply add a few steps and components for deployment after making our changes. So, let's start by establishing the workflow that we will be working with.

Establishing the general development, deployment, and update workflow

When we discuss deployment, we are assuming that we are happy enough with what we have developed so far. This could be when we run our app for the first time, or after having introduced some changes or fixed some bugs. So, our data and code are ready to go. Our focus will be to set up the required infrastructure to enable us to run the code online.

The setup we will be going through is going to be simple and straightforward. We will be using Linode as an example for our hosting provider. An important feature of Linode is that it follows a philosophy of "open cloud." This means that the server we will be working with will be a plain Linux server, using open source components and packages that you can customize the way you want and migrate to and from with ease. The potential challenge here is that with more freedom comes more complexity and responsibility. In Chapter 4, Data Manipulation and Preparation...

Creating a hosting account and virtual server

It's straightforward to set up an account on Linode, and you can do so from the signup page at https://login.linode.com/signup. Once you register and provide your billing information, you can start by creating a "Linode." Virtual servers with their own Internet Protocol (IP) address are also called Linodes (Linux + node), similar to the name of the company.

The process is straightforward and can be done through the main dashboard that you land on when you log in.

The following screenshot shows some of the main options available to create and manage your account:

Figure 12.2 – The main objects that you can create on Linode; most importantly, the "Linode"

Once you select the Create option and then select Linode, you are given several options to choose from. We will go with Distributions. You can think of distributions as bundles of software based on the Linux kernel but containing...

Connecting to your server with SSH

SSH is a protocol for moving data securely, over an unsecured network. This will enable us to get access to and run code from the command line of our server, using the Terminal on our local machine.

Let's start by copying the ssh root@127.105.72.121 command by clicking on the clipboard icon next to it, which you can see in Figure 12.4 as well.

Now, open the terminal application on your local machine and paste the command, as follows:

ssh root@172.105.72.121
The authenticity of host '172.105.72.121 (172.105.72.121)' can't be established.
ECDSA key fingerprint is SHA256:7TvPpP9fko2gTGG1lW/4ZJC+jj6fB/nzVzlW5pjepyU.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '172.105.72.121' (ECDSA) to the list of known hosts.
root@172.105.72.121's password:

As you can see, we had two main responses: one asking if we want to connect and add the IP to the list of known...

Running the app on the server

What we will do in this section is exactly what we did back in Chapter 1, Overview of the Dash Ecosystem. We will clone the code and data repository from GitHub and get them to the server, install the dependencies, and try to run the app.

You typically have Python already installed on such servers, but it's always good to check and know how to get it, in case you don't. An easy way to check if we have it installed, and to get the version in one go, is to run python --version from the command line. Keep in mind that the python command can be interpreted to mean Python 2. The upgrade to Python 3 took a while to get fully implemented, and so, during that time, to differentiate between the two versions the python3 command was used, to be explicit about wanting to run Python version 3. This applies to the pip command, which can also be run as pip3.

When I ran python3 --version, I got version 3.8.6. By the time you read this, the default version...

Setting up and running the app with a WSGI

We have run our app using the python app.py command from the command line. Alternatively, we used the app.run_server method when running with jupyter_dash. We are going to do it now with Gunicorn, our WSGI server.

The command is slightly different from the previous one and is run with the following pattern:

gunicorn <app_module_name:server_name>

We have two main differences here. First, we only use the module name, or the filename without the .py extension. Then, we add a colon, and then the server name. This is a simple variable that we have to define, and it can be done with one line of code, right after we define our top-level app variable, as follows:

app = dash.Dash(__name__)
server = app.server

Now that we have defined our sever as server, and assuming our app is in a file called app.py, we can run the app from the command line, as follows:

gunicorn app:server

That's it for the WSGI server!

Once that...

Setting up and configuring the web server

We will be using nginx as our web server in this example. You can now stop the app using Ctrl + C from the command line. Alternatively, you can stop your app using the kill command, which requires you to know the ID of the process that is running your app. This is useful if you log in later and have no idea which processes are running, and want to identify the process responsible for your app.

You can run the ps -A process status command from the command line to get all the currently running processes. You can either scroll to find a process whose name contains gunicorn or add a pipe, and search for that process in the previous command's output, as follows:

ps -A | grep gunicorn

Running the preceding command while the app is running gets us the output you see in the following screenshot:

Figure 12.8 – How to find the process IDs for processes containing a certain text pattern

The process IDs...

Managing maintenance and updates

Several things will probably need to be managed and handled after publishing your app, and we cover a few of them.

Fixing bugs and making changes

This should follow the same workflow we established at the beginning of this chapter. Any changes to our code, whether bug fixes or additions to our functionality, should be done the same way. We edit code locally, make sure it is running correctly, and then push to the central Git repository. Then, from the server, we pull the changes and rerun the app.

Updating Python packages

There are several packages that our app depends on, and you will most likely have even more in your daily work. Those packages will release updates every now and then, and you need to make sure that they are up to date. Some of those updates are security updates and need to be handled as soon as possible, while others introduce new options to packages. In general, you can run pip install --upgrade <package_name> to...

Deploying and scaling Dash apps with Dash Enterprise

We will now explore several phases and options that go into Dash Enterprise deployment.

Initializing the app

Once you have a contract and your setup is ready, you can go to your Application Manager page to initialize your app. This can be done by clicking the Initialize App button, which will prompt you to name your app. The app name will determine the URL of your application, which will be accessible on the URL https://<your-dash-enterprise-domain>/<app-name> as you can see in Figure 12.9:


Figure 12.10 – Initializing your app on Dash Enterprise

Building your application (optional)

If you have your application already written, you can skip to the following phase. Otherwise, you can use the Dash Enterprise Development Workspaces tool to build your application.

It also contains an isolated production-like environment that allows you to author an app from creation...

Summary

We started by establishing a simple workflow to manage the cycle of development, deployment, and updates. We defined three main components for this workflow and how they relate to one another. We discussed the relationship between local workstations, a central Git repository, and a web server, and set some guidelines on how work should flow between them.

We then created a hosting account, set up a virtual server, and got ready to do work on the server locally. Then, we explored how we can access the server locally through SSH, and ran some basic security and administration tasks. We cloned our repository and saw that it can run on the server exactly as we do locally.

We then discussed the two other required components for our app to be available publicly. We ran our app slightly differently by using a WSGI server. The last step was to install and configure a web server, using the simplest setup possible. Our app was then accessible on a public IP.

Finally, we explored...