了解 Docker 上下文：通过 docker-compose 运行时，Flask 找不到 app.py

Question

I'd like to have docker-compose start an "api" service that is a flask app. My folder structure is as such:

foo/backend/
            Dockerfile
            app.py
            requirements.text
foo/
    docker-compose.dev.yml

There's also a frontend folder which I'll discuss later when demonstrating why I think my current strategy should work.

My backend Dockerfile looks like the following:

foo/backend/Dockerfile

# syntax=docker/dockerfile:1

FROM python:3.8-slim-buster
WORKDIR /app
COPY requirements.txt requirements.txt

RUN pip3 install -r requirements.txt
COPY . .
RUN ls

CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0"]

My docker compose file looks like the following:

foo/docker-compose.dev.yml

version: '3.8'

services:
 api:
  build:
   context: ./backend/
  ports:
  - 5000:5000
  volumes:
  - ./:/app

(I removed the other services for clarity, I'll refer back to them later)

I run docker-compose with the following command:

docker-compose -f docker-compose.dev.yml up --build

My issue is around various errors wherein the app.py file isn't found by flask. For example:

api_1       | Error: Could not locate a Flask application. You did not provide the "FLASK_APP" environment variable, and a "wsgi.py" or "app.py" module was not found in the current directory.

I added the RUN ls command to my Dockerfile because I don't know how to debug a Docker image that won't run (is that the right vocabulary?) and the backend image won't run because it fails with the above error. The RUN ls command indicates that there is an app.py present:

Step 6/7 : RUN ls
 ---> Running in f5f09e4805cc
Dockerfile
__pycache__
app.py
database.conf
requirements.txt

I've tried setting an environment variable two ways: with a file, and then at the direction of a stackoverflow answer directly as an ENV property in the Dockerfile:

Example 1

foo/.dev.env

FLASK_APP=app.py

foo/docker-compose.dev.yml

version: '3.8'

services:
 api:
  build:
   context: ./backend/
  ports:
  - 5000:5000
  env_file:
  - .dev.env
  volumes:
  - ./:/app

Example 2

(consider files reverted to state prior to example 1)

foo/backend/Dockerfile

# syntax=docker/dockerfile:1

FROM python:3.8-slim-buster
WORKDIR /app
COPY requirements.txt requirements.txt

RUN pip3 install -r requirements.txt
COPY . .
RUN ls
ENV FLASK_APP=app.py

CMD [ "python3", "-m" , "flask", "run", "--host=0.0.0.0"]

Bot examples result in:

api_1       | Error: Could not import 'app'.

I suspect this issue has something to do with contexts that commands are being run in, but I don't understand why it doesn't work for backend , when it does for frontend . Here's the frontend portion of my docker-compose:

foo/docker-compose.dev.yml

version: '3.8'

services:
 frontend:
   build:
     context: ./frontend/
   ports:
   - 8080:8080

And my frontend Dockerfile:

foo/frontend/Dockerfile

# syntax=docker/dockerfile:1
FROM node:16

WORKDIR /app
COPY package*.json ./

RUN yarn

COPY . .
CMD [ "yarn", "run", "serve" ]

The frontend correctly runs and remains spun up.

How can I determine the context in which a Dockerfile command is run? Why isn't my python CMD able to find the app.py file that, to me, seems to be visible in the proper location to it?

Answer 1

You have a volumes: block that's overwriting the /app directory in the container with entirely different content. If you delete that block, you'll run the code that's built into the image.

Some Docker tutorials will tell you to bind-mount host content into your image. The idea is that this simulates a live-development environment, so if you change your application code you don't have to restart the application. In your case, the directory you're mounting into the container is different from what you built the image, so you're getting inconsistent behavior. In most cases you should be able to use an actual local development environment to build your application, and then run it in Docker (without a volumes: bind-mount; running the actual code in the image) for integration testing and deployment.