Docker-Compose: Getting Flask up and running

A couple of issues were resolved in PyCharm 2017.1, and Docker for Mac should now work out of the box. In this blog post we’ll show you how to set up a project with Docker Compose on a Mac. If you’re on Linux, the process is very similar. Docker Compose is supported on Windows from PyCharm 2017.2.

In this tutorial we’ll show how to create a very simple ‘Hello World’ Flask application, and then how to run it within a Docker container. For the full code, and to follow along, see GitHub: https://github.com/ErnstHaagsman/flask-compose.

First things first

Before we get started, let’s check a couple of things: make sure you are using PyCharm 2017.1 Professional Edition or later. Docker support is not available in PyCharm Community Edition. Then, please ensure your Docker and Docker Compose are up to date. To check, open a terminal, and run docker -v, and docker-compose -v:

Then, although it is the default setting in PyCharm 2017.1, it never hurts to check that your Docker API URL (Preferences | Build, Execution, Deployment | Docker) is set to unix:///var/run/docker.sock.

Now we can create a new Flask project. Let’s create a virtualenv so that PyCharm can stub out our Flask project before we have Docker configured. You can create a Virtualenv by using the ‘…’ button next to the interpreter dropdown.

Dockerizing Flask

After you click create, you should see the standard “Hello World” Flask template. So let’s see if we can get Flask to show us “Hello World” from a Docker container. To do this, we’ll add four files:

requirements.txt, just put “Flask==0.12” here to install Flask

Dockerfile, where we will set up the Python environment for the Flask app

docker-compose.yml to set up how to run the Dockerfile, and add a database

docker-compose.dev.yml to make some changes for local development

In the Dockerfile, we’ll use the ‘python:3’ image, expose port 5000, install packages from requirements.txt, and afterwards copy the rest of our project into /app. See the full file on GitHub.

Then, we’ll create a Compose file where we define the Flask app as our only service (for now). Just use build: . to make Docker Compose build the container from the Dockerfile.

Docker will bake our code into the image, and that way the image is self-contained. If we wanted to, we could stop here and rebuild our image whenever we change the code. It makes development quite a bit faster to mount our code with a volume. So we’ll create an additional Compose file to do that while we’re developing.

In docker-compose.dev.yml, all we’re doing is adding a volume mapping for .:/app for the web service. This overlays the code in the container with a volume, making sure that code changes are applied immediately. Keep in mind that you will need to rebuild the image before pushing it anywhere.

Now that everything is configured, let’s quickly run docker-compose up in the Terminal to make sure that works. Open the terminal with Alt+F12 (in PyCharm) and run docker-compose up.

As we can see, Docker built our container, and Flask is running! Let’s go and check out our ‘Hello World’ message!

A trap for young players!

What happened here? Didn’t docker say that Flask was running?

For security reasons, many modern web frameworks actually limit incoming connections to only come from localhost. This means that our Flask app is running, but only accessible from within the Docker container, not from our Mac host. The easiest way to fix this is to add host='0.0.0.0' as a keyword argument to app.run() in flask-compose.py:

This change tells Flask to listen not only to requests from localhost (in this case the docker container), but on all network connections. In the case of our container this means we can access it from our host, and depending on configuration from other computers in our network.

If we now stop our container (Ctrl+C in the PyCharm Terminal), and rebuild it by running docker-compose up --build. We can see in the Docker Compose output that Flask is now listening on 0.0.0.0 instead of 127.0.0.1:

And reloading the page in Safari actually shows ‘Hello World’ now. So let’s stop the container (Ctrl+C in the Terminal), and then configure PyCharm.

Configuring PyCharm

To make our project run using a PyCharm run configuration, we need to set the project interpreter to the Docker Compose service. We can do this from the Project interpreter page in preferences: Preferences | Project: <Project Name> | Project Interpreter.

Click the little button next to the interpreter dropdown (the white one, not the blue one), and choose “Add Remote”. If you don’t see “Add Remote” here, you may be using PyCharm Community Edition, which doesn’t support remote interpreters.

Now choose “docker-compose”, and almost everything will be pre-configured, I only had to add the docker-compose.dev.yml configuration to the list. We need to add it manually as this isn’t part of a standard docker project. You can do this with the ‘+’ button underneath the list of configuration files.

Now, we should set up the path mapping. We are inserting all our project code into the container’s “/app” directory. So let’s add this on the Project Interpreter screen, use the ‘…’ button next to the Path mappings field to change them.

After you close the preferences window, you can just use the regular Run and Debug buttons to start and debug your project:

To celebrate, let’s change “Hello World!” to “Hello from Docker within PyCharm!”

The arrival of “proper” Compose support in 2017.1 has been as frustrating as it has been long-awaited. Essentially, it arrived just in time to be obsolete.

For one thing, PyCharm doesn’t support the new Version 3 of the compose file format, which is the now the version recommended by Docker, Inc. I had to roll back a few projects to Version 2 compose files for them to work with PyCharm. (Basically it’s forcing me to maintain git branches with both Version 2 and Version 3 compose files.)

And secondly, Version 3 compose files are themselves a stepping stone to the complete phasing out of Docker Compose in favour of the newer Docker Stacks — which, obviously, aren’t supported by PyCharm at all yet.

I’m not blaming the JetBrains guys. Docker is currently iterating at high speed… much faster than an IDE’s release cycle.

Unfortunately, it doesn’t. It’s hard for us to do things with Docker on Windows because of Hyper-V. After installing Hyper-V on Windows you can’t run other virtualization software anymore. We’d essentially need to use separate hardware to develop our support for Docker on Windows.

How are you using Docker on Windows? Are you using it natively or are you connecting to a docker server running remotely, or in VMWare, or Virtualbox?

I’m using docker-compose on Windows (natively with hyper-v, no virtual machine) but hit a wall with PyCharm. Right now, I setup my app to provide only dependencies and run the app on Windows, but I would much rather have the app also run in docker as it is possible on Linux.

Hi Jonathan, currently we don’t support Docker Compose on Windows unfortunately. Hyper-V is incompatible with other virtualization, and therefore we’d need to work on separate hardware to develop Docker for Windows. This means it’s very hard for us to work on supporting Docker for Windows.

Just curious – what’s specific about Compose? You do support “bare” Docker for Windows (or at least in works for me, huh), just not the Compose. And Compose doesn’t really care about the OS (sans a few oddities), it mostly just talks to the Docker API to spawn stuff as described, (almost) blindly passing the params there.

I was having an issue where it seemed like the docker-comose.dev.yml was not mounting my app, so I couldn’t see my changes reflected without restarting the app every time. I changed the file name to docker-compose.override.yml, and that seems to have fixed the problem.

Honestly speaking selecting flask app without database support for demonstrating Docker related IDE functionality is a bad choice IMHO since it is trivial to do it with simple Dockerfile and no IDE at all in the first place. The only possible (and trivial) catch to the whole – already noted in the post – is setting up host=’0.0.0.0′ so the app can be accessible outside of container.

Agree with comments that it is way too late, not to mention I am still using Windows so the whole thing is double useless.

Thanks for the article, the binding to localhost instead of 0.0.0.0 was tripping me up.
Also, running python inside a virtualenv inside a docker container *is* possible, but it requires a wrapper script to be created which activates the virtualenv and executes whatever python command. This is then specified as the python interpreter instead of any particular binary.

I’m a mac/linux user, but the fact PyCharm can’t support Windows effects even me. In every team, where platform independency is a must, due windows platform it’s not evident to go with PyCharm, if the team can not use it as a whole. You know how it works… if anybody who is a bit afraid of PyCharm will tell the “management” about this leak, or just argue due that and the whole boat with mac and linux people will sink as well.

“There is always a windows guy in the team.”

Can you say anything about its support? Even if you can mark a date until it’s not going to happen or a date until it might happen could help.

awesome feature. I just managed to make it work (with pyramid). However, when debugging, it seems I am unable to use the console in a breakpoint. (even though the variables etc. seem to be known by the debugger and breakpoints work)
Any ideas?
thx

Firstable, thanks to Ernst Haagsman per this post. For us is very usefull. I have follow every step and have this app up and running. Only thing I found is when I click on “python console” tool, I get an error:
“Error: Unable to locate container name for service “web” from docker-compose output”

I am an IntelliJ IDEA Ultimate developers, and I have been trying to follow this tutorial to make Python debugging with Docker using IntelliJ, but there are a few steps that I couldn’t quite locate in IntelliJ Ultimate 17.2 EAP. For example, I cannot seem to be able to locate Project Path Mapping dialog, and add remote interpreter was an option quite hidden in IntelliJ as well. I wonder if you could point me the directions to get the same functionality working in IntelliJ IDEA, thanks!

Unfortunately, no. If we were to keep the dependencies only in the container, access to them would be very slow, and it would impede the development experience. We’re currently working on ways to optimize the synchronization process, however, you’ll always need a local copy of the files.

So if see how it works now, each time you start a run a new cache folder is created with a copy of the library files.
It would be cool, if pycharm would create this once and keep it it the same, until you ask pycharm to update these. That way, if you need to put breakpoints before pycharm dowloaded the files (e.g. on init of a module), you can do so without manually putting the files somewhere and mapping it etc…

OK I followed everything and got it working brilliantly. Some things have changed, but that’s progress. For example I did not have to do the linux socket thing, as it was now just a radio button to select 😀

However, I added
”’
app.run(host=’0.0.0.0′, debug=True)
”’

Then ran it plainly from PyCharm and tried to modify the returned results. It did not reload automatically. I tried debugging and modify the result again, but still it refused to refresh.

What I ended up doing was stopping the process, then in the terminal ran
”’
docker-compose build
”’

then ran it as normal in order to see the changes.
Why is not refreshing ?
Is this a limitation of the system or am I missing something ?

To make file changes visible in the container, you need to use a volume to overlay the code you’ve added with an ‘ADD’ statement in the Dockerfile. In this example, we’re configuring this in the docker-compose.dev.yml file. Did you add this file in the interpreter settings? Without that addition you’d need to rebuild your containers after every change.

I’m having trouble getting this to work in PyCharm 2017.4.
I can run app fine via my commandline and running docker-compose, however when I run the debugger in PyCharm it only prints in the console that it is ‘Waiting for connection…’ and after a minute the docker container is killed:

I created a Python config to run the app with the remote docker-compose interpreter, and I set up the path mapping to be equivalent to my Dockerfile and docker-compose files.
When I run docker ps while the debugger is waiting for connection.. I can see that the docker container is running and exposing the debugging port (55223 in this case).

Same here.
The guide doesn’t work with 2018.2 and Docker 18.06.1-ce-mac73 (26764)
Specifically, starting flask from PyCharm with the docker remote interpreter binds to 127.0.0.1 and port 5000 regardless of the host and port kwargs

There have been some changes in Flask since this blog post was written. Use a Flask run configuration rather than a Python run configuration, and provide the new host and port in ‘Additional Options’. See the Flask run configuration docs for more details

Thank you for this article, it really helped me to make my debugger work.
I forgot to add the path mapping to the remote interpreter and the debugging was not working (I assumes that the path mapping is taken from docker-compose file).