Try running TEKDB locally with docker

[paigewilliams]

so far this works?! Shout out to my pal copilot for helping a lot here. Not looking to merge anytime soon, but wanted to show the progress so far with the draft pull request.

Definitely a work in progress, but I mostly wanted to see how far I could get to getting ITKDB running in docker in an afternoon.

pre-requisite: installing docker desktop

• build and start the containers with docker compose up -d --build
• stop the containers with docker compose down

TODO:

• css + js libraries load correctly

[Copilot]

Pull Request Overview

This PR modernizes Docker configuration for the TEKDB application, introducing a complete containerization setup with proper orchestration. The changes implement database health checks, proper initialization sequencing, and production-ready configurations.

• Updates entrypoint script with database readiness checks and fixture loading
• Modernizes docker-compose with health checks and proper service dependencies
• Adds comprehensive Dockerfile with GDAL/PostGIS support
• Includes .dockerignore for optimized build context

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File	Description
TEKDB/docker/entrypoint.sh	Enhanced startup script with database wait logic, fixture loading, and HTTP socket configuration
TEKDB/docker-compose.yml	Restructured compose file with PostGIS 15, health checks, and environment variable configuration
TEKDB/Dockerfile	New multi-stage Python 3.11 image with geospatial dependencies and optimized layer caching
TEKDB/.dockerignore	Build context exclusions to reduce image size and avoid copying unnecessary files

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Loading fixtures on every container start can cause failures if the data already exists or if unique constraints are violated on subsequent restarts. Consider wrapping these loaddata commands in a conditional check or using --ignorenonexistent flag, or better yet, moving them to a separate initialization script that runs only once.

Suggested change

	python manage.py loaddata TEKDB/fixtures/default_users_fixture.json
	python manage.py loaddata TEKDB/fixtures/default_lookups_fixture.json
	# Load default users only if no users exist
	if [ "$(python manage.py shell -c 'from django.contrib.auth import get_user_model; print(get_user_model().objects.count())')" = "0" ]; then
	python manage.py loaddata TEKDB/fixtures/default_users_fixture.json
	fi
	# Load default lookups only if no lookups exist
	if [ "$(python manage.py shell -c 'from TEKDB.models import Lookup; print(Lookup.objects.count())')" = "0" ]; then
	python manage.py loaddata TEKDB/fixtures/default_lookups_fixture.json
	fi

[rhodges]

Had to review that = was the correct syntax for comparison in shell, but it checks out.

[Copilot]

The exec \"$@\" line at line 28 is unreachable because the uwsgi command on line 27 runs in the foreground and never returns. Either remove line 28 or run uwsgi in the background with & if you need to execute additional commands.

Suggested change

exec "$@"

[Copilot]

Line 37 is redundant as line 38 already copies requirements.txt along with requirements_linux.txt. Remove line 37 to avoid the duplicate COPY operation.

Suggested change

COPY requirements.txt /usr/src/app/

[Copilot]

Installing the full PostgreSQL server (postgresql and postgresql-contrib) in the application container is unnecessary and significantly increases image size. Only postgresql-client and postgresql-client-common (already included on lines 11-12) are needed for database connections and pg_isready. Remove lines 14-15.

Suggested change

	postgresql \
	postgresql-contrib \

[rhodges]

@paigewilliams - is Copilot suggesting running the PostgreSQL instance in a separate container here? I like the modularity, but having everything in a single container sounds simpler for our users. Happy to default to whatever you feel is best, or hold further conversations to align our actions with strategy.

[Copilot]

Hardcoding SECRET_KEY directly in docker-compose.yml is a security risk, even with a placeholder value. This should be loaded from the .env.dev file or injected as an environment variable at runtime to prevent accidental commits of sensitive values.

Suggested change

SECRET_KEY: 'change-me'

[Copilot]

DEBUG mode is hardcoded to '0' (False) in the docker-compose.yml, but this file appears to be for development based on the .env.dev reference. Consider setting DEBUG: '1' for local development or removing this line to allow the .env.dev file to control the DEBUG setting.

Suggested change

DEBUG: '0'

[pollardld]

I don't know Docker well enough to review. If it works than approved!

[rhodges]

Like @pollardld , I'm not confident enough in my Docker knowledge to validate the correctness of the code, but in general it looks good, and it's not going to hurt anything by including (since Docker isn't currently part of anyone's deployment). I look forward to playing with this more in the future. Approved