debug_toolbar module is not persisted after docker down / docker up

Question

I started a new project using Django. This project is build using Docker with few containers and poetry to install all dependencies.

When I first run docker-compose up -d, everything is installed correctly. Actually, this problem is not related with Docker I suppose.

After I run that command, I'm running docker-compose exec python make -f automation/local/Makefile which has this content

Makefile

.PHONY: all
all: install-deps run-migrations build-static-files create-superuser

.PHONY: build-static-files
build-static-files:
    python manage.py collectstatic --noinput

.PHONY: create-superuser
create-superuser:
    python manage.py createsuperuser --noinput --user=${DJANGO_SUPERUSER_USERNAME} --email=${DJANGO_SUPERUSER_USERNAME}@zitec.com

.PHONY: install-deps
install-deps: vendor

vendor: pyproject.toml $(wildcard poetry.lock)
    poetry install --no-interaction --no-root

.PHONY: run-migrations
run-migrations:
    python manage.py migrate --noinput

pyproject.toml

[tool.poetry]
name = "some-random-application-name"
version = "0.1.0"
description = ""
authors = ["xxx <xxx@xxx.com>"]

[tool.poetry.dependencies]
python = ">=3.6"
Django = "3.0.8"
docusign-esign = "^3.4.0"

[tool.poetry.dev-dependencies]
pytest = "^3.4"
django-debug-toolbar = "^2.2"

Debug toolbar is installed by adding those entries under settings.py (MIDDLEWARE / INSTALLED_APP) and even DEBUG_TOOLBAR_CONFIG with next value: SHOW_TOOLBAR_CALLBACK.

Let me confirm that EVERYTHING works after fresh docker-compose up -d. The problem occurs after I stop container and start it again using next commands:

• docker-compose down
• docker-compose up -d

When I try to access the project it says that Module debug_toolbar does not exist!.

I read all questions from this website, but nothing worked for me.

Has anyone encountered this problem before?

Answer 1

That sounds like normal behavior. A container has a temporary filesystem, and when the container exits any changes that have been made in that filesystem will be permanently lost. Deleting and recreating containers is extremely routine (even just changing environment: or ports: settings in the docker-compose.yml file would cause that to happen).

You should almost never install software in a running container. docker exec is an extremely useful debugging tool, but it shouldn't be the primary way you interact with your container. In both cases you're setting yourself up to lose work if you ever need to change a Docker-level setting or update the base image.

For this example, you can split the contents of that Makefile into two parts, the install_deps target (that installs Python packages but doesn't have any external dependencies) and the rest (that will depend on a database running). You need to run the installation part at image-build time, but the Dockerfile can't access a database, so the remainder needs to happen at container-startup time.

So in your image's Dockerfile, RUN the installation part:

RUN make install-reps

You will also need an entrypoint script that does the rest of the first-time setup, then runs the main container command. This can look like:

#!/bin/sh
make run-migrations build-static-files create-superuser
exec "$@"

Then run this in your Dockerfile:

COPY entrypoint.sh .
ENTRYPOINT ["./entrypoint.sh"]
CMD python3 manage.py runserver --host 0.0.0.0

(I've recently seen a lot of Dockerfiles that have just ENTRYPOINT ["python3"]. Splitting ENTRYPOINT and CMD this way isn't especially useful; just move the python3 interpreter command into CMD.)