Running Flask with an SSH Remote Python Interpreter

One common cause of bugs in many applications is that development and production environments differ. Although in most cases it’s not possible to provide an exact copy of the production environment for development, pursuing dev-prod parity is a worthwhile cause.

Most web applications are deployed to some sort of Linux VM. If you’re using a traditional web-host, this is referred to as VPS hosting.

If we want to develop in an environment similar to our production environment, how could we approach this? The closest would be to set up a second VM for development purposes. So let’s have a look to see how we can connect PyCharm to a VPS box.

Our Application

I’m lazy, so we’ll use a web-app that I made last year as an example. The application is a very simple old-school guestbook. In last year’s blog post, I used Docker Compose to describe an environment with both the Python service and a PostgreSQL database.

Let’s start by cloning the repository, and then checking out the ‘with-database’ branch. After opening the project, we need to configure our server. I’ll be using an AWS EC2 instance, but you can use any other Linux box (including a Raspberry Pi). 

To configure the interpreter, open Settings | Project Settings, and use the gear icon to add an interpreter:

Add Interpreter

Choose SSH on the left-hand side. If you don’t see SSH, please make sure you’re using PyCharm Professional 2018.1 or later. Then, follow the instructions to connect to your SSH box:

Connect to SSH

For this tutorial, we’ll mostly accept the default values. The only exception is if your Linux box only has Python 3 installed, and doesn’t link /usr/bin/python to that version. As this is the case for AWS current Ubuntu 16.04 AMI, we’ll make sure to change the interpreter path:

Add SSH interpreter - step 2

After we finish configuring the interpreter, we’re ready to run code. For example, if you open the Python console, you can run code on your remote box:

Remote Python Console

Before we can run our Flask script, there are a couple more things we need to take care of.

Configuring Our Box

Docker Compose is very handy, as it allows us to specify and configure services in a very concise way. If we want to make this work on a general Linux machine, we’ll need to handle this configuration ourselves. So let’s start with installing PostgreSQL.

To open an SSH session, either go to Tools | Start SSH session, or use Ctrl+Shift+A to find the ‘Start SSH session’ action:

Start SSH session

At this point, we could just run sudo apt-get install postgresql. If you’re experimenting on your Raspberry Pi, that’s the way to go. If we’re developing an application, it makes sense to document what we’re doing and make sure that we can reproduce the environment later.

A great tool for configuring the state of a Linux machine is Ansible. With Ansible, we can describe the desired state of our Linux server in YAML files, and then use the Ansible tooling to apply the desired configuration.

Installing PostgreSQL with Ansible looks like this:

If we create a new file setup.yml with those contents, PyCharm will then automatically upload it to the location we configured during project configuration. By default, this is a subfolder of /tmp/. So let’s install Ansible, navigate to this folder, and run this file (called a playbook in Ansible terminology). You can do this by running these commands on the server (use the SSH session you started earlier):

And look at that, PostgreSQL is installed:

Ansible Output

We can do some more cool things with Ansible, like configuring our virtualenv:

After we add these tasks to our playbook (setup.yml) and re-run them, we can then re-configure PyCharm to use the remote venv rather than our box’s system interpreter. In order to do so, go back to the interpreter settings screen. Use the gear icon to choose ‘Show all’, and then click the pencil to edit the interpreter. Change the path to the Python executable inside the virtualenv (/home/ubuntu/venv/bin/python):

Change interpreter

Now that we’ve taken care of that, we can run our Flask run configuration. Let’s edit it first, so it’s accessible from the outside world. We need to provide host=0.0.0.0 as an additional option to Flask:

Flask Run Configuration

If you’re running this code on AWS or a similar provider, you may need to open port 5000 in the firewall. On AWS you need to add a new rule to the security group to allow inbound traffic on TCP port 5000 from 0.0.0.0/0.

Now click the debug button to start Flask:

Flask Starts

Let’s visit our page!

500 Error

In the wise words of Butters Stotch: oh hamburgers. If we look back at PyCharm, we should see the stack trace in the debug window, which shows us that we still need to finish up the database connection.

In the Flask application, the database host was set to ‘db’ for the Docker Compose configuration. Let’s change that to 127.0.0.1:

We also need to actually create the database, and create the tables. Thankfully our friend Ansible can help us with that! To keep this blog post a little bit shorter, I’ll skip the details. Just check out the ‘ansible’ branch of the repo. Then run the following SSH commands:

The first playbook configures the PostgreSQL user account. The second playbook deletes the database if it exists, and then creates a clean database. In this clean database, the schema.sql file is run to create the table necessary for this application.

You can also use PyCharm to run SQL commands and inspect the database. Read our blog post about running code on a Raspberry Pi to learn how.

The Finish Line

After setting up the database, we should be able to start Flask again with the debug configuration, and check out our cool guestbook:

Results

Of course, if we were to put a breakpoint in our code, we’d be able to hit it now. Try it out, and let us know how it went!

If you’re interested in DevOps and you’d like to learn more: check out our advanced AWS tutorial, our Raspberry Pi tutorial, or our Docker Compose tutorial. Let us know in the comments if there’s anything else you’d like to learn about!

This entry was posted in Tutorial and tagged , , , , , . Bookmark the permalink.

7 Responses to Running Flask with an SSH Remote Python Interpreter

  1. I like PyCharm in theory, but it doesn’t match my use case where everything is remote: svn/git, SQL server, Python interpreter, python code, … everything but the IDE. I can do that with Notepad++ and Putty and WinSCP. But PyCharm so far only supports a remote interpreter. Any hope for my use case being supported?

    • Ernst Haagsman says:

      How do you mean? If you set up deployment code will be synced between your computer and the remote computer. If you use git remotely, you’d need to run the git commands over SSH and PyCharm won’t be aware of it. PyCharm will always need a local copy of the files for performance reasons, but with deployment configured it’ll keep it synchronized for you.

      • Arthur Pemberton says:

        > PyCharm will always need a local copy of the files for performance reasons

        What are those performance reasons? What can’t PyCharm not do over SSH if it chose to? At any one point in time, I only technically have the 3 or 4 .py (or .css, .js) files that I’m editing on my local machine, and those get saved to the remote machine every time I hit Ctrl+S

        • Ernst Haagsman says:

          We index your code (and packages you use) to give you code intelligence. That’s how we can make it possible for you to quickly navigate around your code and offer code completion. This requires a fair amount of disk I/O. We also watch the filesystem for changes to make sure you don’t work on files that have been changed externally.

  2. Tim says:

    You can mount remote locations as a local drive with sshfs but your request implies that you are developing on your production environment, which is unusual I think.

  3. arshad says:

    i want to run flask on pycharm 2018 community edition so please help me on email

  4. Pingback: Python-树莓派远程开发 – DragonHao's Bolg

Leave a Reply

Your email address will not be published. Required fields are marked *