SgtBilko
SgtBilko

Reputation: 55

ModuleNotFoundError: No module named” when run in docker

I have the following Django project which runs perfectly in non-docker debug mode.

xxxProjectv3
│   ├── asgi.py
│   ├── celery.py
│   ├── __init__.py
│   ├── settings
│   │   ├── development_settings.py
│   │   ├── django_settings.py
│   │   ├── __init__.py
│   │   ├── production_settings.py
│   │   └── project_settings.py
│   ├── urls.py
│   └── wsgi.py
├── CCTV
│   ├── admin.py
│   ├── apps.py
│   ├── camera.py
│   ├── consumers.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── routing.py
│   ├── tasks.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── celerybeat-schedule.db
├── db.sqlite3
├── docker-compose.yml
├── Dockerfile
├── dome_control
│   ├── admin.py
│   ├── apps.py
│   ├── conditions.py
│   ├── consumers.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── relays.py
│   ├── routing.py
│   ├── tasks.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── home
│   ├── admin_bak.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   ├── urls.py
│   └── views.py
├── manage.py
├── requirements.txt
├── shared_data
│   ├── conditions.json
│   ├── debug.log
│   ├── django.log
│   ├── relays.json
│   └── temperhum.json
├── static
│   ├── bootstrap.bundle.js
│   ├── bootstrap.bundle.js.map
│   ├── bootstrap.css
│   ├── bootstrap.css.map
│   ├── grey.css
│   ├── home.css
│   ├── jquery-3.2.1.js
│   ├── main.css
│   ├── reconnecting-websocket.js
│   ├── video.js
│   └── video-js.css
├── temperhum
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tasks.py
│   ├── tests.py
│   └── views.py

As part of moving to production I am running the project in a docker.

# pull official base image, call it "base"
FROM python:3.9.13-bullseye as base

RUN apt update -y && apt upgrade -y
# set work directory
RUN mkdir -p /xx/devATP
WORKDIR /xx/devATP
#Prevents Python from writing pyc files to disc
ENV PYTHONDONTWRITEBYTECODE 1 
#Prevents Python from buffering stdout and stderr
ENV PYTHONUNBUFFERED 1

FROM base as django
# install venv
RUN python3 -m venv /xx/devATP/venv
# enable venv
ENV PATH="/xx/devATP/venv/bin:$PATH"
# install dependencies
RUN pip install --upgrade pip
#RUN pip install --upgrade pip
COPY requirements.txt /xx/devATP/
# special pip install as in docker install doesn't call piwheels
# and tries to make a number of dependencies from scratch (crypotgraphy fails)
RUN pip3 install --index-url=https://www.piwheels.org/simple --no-cache-dir -r requirements.txt

COPY . /xx/devATP

The relevant part of the docker-compose file is

services:
  daphne:
    image: django:latest
    container_name: daphne
    privileged: true
    command: daphne -b 0.0.0.0 -p 8000 xxxProjectv3.asgi:application
    # command: python manage.py runserver 0.0.0.0:8000
    environment:
      - settings_file=production
     #- settings_file=development     
    ports:
      - "8000:8000"
    volumes:
      - static:/xxx/devATP/static
      - data:/xxx/devATP/shared_data #copy logs
    restart: on-failure
    depends_on:
      - redis

When I run docker-compose I get the following error:

daphne    | 2022-06-12 12:17:58,115 [INFO] django.utils.autoreload: Watching for file changes with StatReloader
daphne    | Exception in thread django-main-thread:
daphne    | Traceback (most recent call last):
daphne    |   File "/usr/local/lib/python3.9/threading.py", line 980, in _bootstrap_inner
daphne    |     self.run()
daphne    |   File "/usr/local/lib/python3.9/threading.py", line 917, in run
daphne    |     self._target(*self._args, **self._kwargs)
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/utils/autoreload.py", line 64, in wrapper
daphne    |     fn(*args, **kwargs)
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/core/management/commands/runserver.py", line 125, in inner_run
daphne    |     autoreload.raise_last_exception()
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/utils/autoreload.py", line 87, in raise_last_exception
daphne    |     raise _exception[1]
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/core/management/__init__.py", line 398, in execute
daphne    |     autoreload.check_errors(django.setup)()
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/utils/autoreload.py", line 64, in wrapper
daphne    |     fn(*args, **kwargs)
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/__init__.py", line 24, in setup
daphne    |     apps.populate(settings.INSTALLED_APPS)
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/apps/registry.py", line 91, in populate
daphne    |     app_config = AppConfig.create(entry)
daphne    |   File "/xxx/devATP/venv/lib/python3.9/site-packages/django/apps/config.py", line 213, in create
daphne    |     mod = import_module(mod_path)
daphne    |   File "/usr/local/lib/python3.9/importlib/__init__.py", line 127, in import_module
daphne    |     return _bootstrap._gcd_import(name[level:], package, level)
daphne    |   File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
daphne    |   File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
daphne    |   File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked
daphne    | ModuleNotFoundError: No module named 'temperhum.apps'

I have checked a number of threads and spend some hours trying to trouble shoot.

Upvotes: 0

Views: 5960

Answers (1)

SgtBilko
SgtBilko

Reputation: 55

Found the issue.

Using ....https://vsupalov.com/debug-docker-container/ and specifically

$ docker run -it --entrypoint /bin/bash $IMAGE_NAME -s

I was able to spot that there was no content in the temperhum app. It looked like it was being copied by the Dockerfile becuase I had previously seen that the folder existed. In a previous version of this project I had run temperhum in a seperate docker...... so duh ! The contents were included in a .dockerignore file.

Upvotes: 2

Related Questions