This commit significantly improves the gatekeeper system's robustness, monitoring capabilities, and simplifies host header management for backend services.
Key changes include:
**Gatekeeper Health, Management & Resilience:**
- Implemented active health checking for individual gatekeeper containers within the `gatekeeper-manager` service.
- The manager now periodically curls the `/metrics` endpoint of each gatekeeper container.
- Reports health status to a new Gatus `services_gatekeeper` endpoint.
- Automatically attempts to restart the gatekeeper stack if any gatekeeper instance is unhealthy or if the expected number of gatekeepers is not running.
- Refactored the `gatekeeper-manager` shell script for improved state management and signal handling:
- Introduced `STARTED`, `RESTARTING`, `TERMINATING` state flags for more controlled operations.
- Enhanced SIGTERM and SIGHUP handling to gracefully manage gatekeeper lifecycles.
- Added `apk add curl` to ensure `curl` is available in the manager container.
- Renamed the gatekeeper Docker Compose template from `docker-compose_gatekeeper.template.yml` to `gatekeepers.template.yml` and its output to `gatekeepers.yml`.
- Updated `dockergen-gatekeeper` to watch the new template file and notify the correct `gatekeeper-manager` service instance (e.g., `pkmntrade-club-gatekeeper-manager-1`).
- Discover services that should be protected by looking for a `gatekeeper=true` label.
**Host Header Management & `ALLOWED_HOSTS` Simplification:**
- HAProxy configuration (`haproxy.cfg`) now consistently sets the `Host` HTTP header for requests to all backend services (e.g., `pkmntrade.club`, `staging.pkmntrade.club`). This centralizes and standardizes host information.
- Consequently, explicit `ALLOWED_HOSTS` environment variables have been removed from the `web` and `celery` service definitions in `docker-compose_web.yml` and `docker-compose_staging.yml`. Backend Django applications should now rely on the `Host` header set by HAProxy for request validation.
- The `gatekeepers.template.yml` now defines a `TARGET_HOST` environment variable for proxied services (e.g., `web`, `web-staging`). This aligns with the ALLOWED_HOSTS on the target to ensure requests aren't blocked.
**Gatus Monitoring & Configuration Updates:**
- In Gatus configuration (`gatus/config.template.yaml`):
- The "Redis" external service endpoint has been renamed to "Cache" for better clarity and to fit the theme of simple names.
- A new external service endpoint "Gatekeeper" has been added to monitor the overall health reported by the `gatekeeper-manager`.
- Health checks for "Web Worker" endpoints (both main and staging) now include the appropriate `Host` header (e.g., `Host: pkmntrade.club`) to ensure accurate health assessments by Django.
- In `docker-compose_core.yml`, the `curl` commands used by `db-redis-healthcheck` for database and cache health now append `|| true`. This prevents the script from exiting on a curl error (e.g., timeout, connection refused), ensuring that the failure is still reported to Gatus via the `success=false` parameter rather than the script terminating prematurely.
These changes collectively make the gatekeeper system more fault-tolerant, provide better visibility into its status, and streamline the configuration of backend applications by standardizing how they receive host information.
|
||
|---|---|---|
| .devcontainer | ||
| .github/workflows | ||
| .vscode | ||
| scripts | ||
| seed | ||
| server | ||
| src/pkmntrade_club | ||
| .cursorrules | ||
| .dockerignore | ||
| .envrc | ||
| .gitignore | ||
| .python-version | ||
| CONTRIBUTING.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| fly.toml | ||
| LICENSE | ||
| locustfile.py | ||
| manage.py | ||
| MANIFEST.in | ||
| pyproject.toml | ||
| README.md | ||
| uv.lock | ||
PKMN Trade Club
PKMN Trade Club is a Django-powered application built to connect Pokémon TCG Pocket trading enthusiasts in a secure, scalable, and community-driven environment. This platform leverages Django’s robust features and stability, a modular project structure, and best practices to deliver a smooth trading experience.
Table of Contents
Features
- Django & Python: Built with Django 5.1 and Python 3.12.
- Modular Architecture: Separate Django apps for trades, accounts, cards, and more.
- User Authentication: Comprehensive authentication powered by Django Allauth.
- Responsive UI: Custom theming with Tailwind CSS, DaisyUI, and AlpineJS.
- Production-Ready: Docker and PostgreSQL configuration for scalable deployments.
- Development Tools: Built-in support for migrations, testing, and seeding initial data.
- Security & Performance: Carefully configured for deployment with production best practices.
Installation
Local Development
-
Clone the repository:
git clone https://git.badblocks.dev/badbl0cks/pkmntrade.club.git cd pkmntrade.club -
Install dependencies via uv:
uv pip install -r requirements.txt -
Configure environment variables:
Copy the example environment file and update credentials as needed:
cp .env.example .env -
Apply migrations and seed initial data:
python manage.py migrate python manage.py createsuperuser python manage.py createcachetable django_cache -
Start the development server:
uv run manage.py runserverVisit http://127.0.0.1:8000 in your browser.
Docker Deployment
-
Build and run containers:
docker-compose up -d --build -
Run migrations and create a superuser inside the container:
docker-compose exec web python manage.py migrate docker-compose exec web python manage.py createsuperuser docker-compose exec web python manage.py createcachetable django_cache -
Access the site:
Configuration
-
Environment Variables:
Manage your local vs. production settings using.envand.env.production. Update these to match your database credentials, secret keys, and other configurations. -
Django Settings:
Production settings are indjango_project/settings.py. -
Database Settings:
Example configuration for PostgreSQL:DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'postgres', 'USER': 'postgres', 'PASSWORD': 'postgres', 'HOST': 'db', # as defined in docker-compose.yml 'PORT': 5432, } }
Database
The platform uses PostgreSQL as its primary database in production. For local development, you may use SQLite or configure PostgreSQL by updating your settings and environment variables as needed.
Running Tests
Run Django’s testing suite with:
python manage.py test
Deployment
For production deployments consider these additional steps:
- Production Server: Use a web server like Gunicorn.
- Static Files: Serve static files using Django’s WhiteNoise (or via a CDN).
- Fly.io Configuration: A
fly.tomlfile is provided if you wish to deploy on Fly.io. - Deployment Scripts: Use
deploy.shfor automated deployment tasks. - Security & Email: Update
DEFAULT_FROM_EMAIL,ALLOWED_HOSTS, and other security settings indjango_project/settings.py.
Contributing
Contributions, feature requests, and issues are welcome! Please refer to CONTRIBUTING.md for details on how to contribute to PKMN Trade Club.
License
This project is licensed under the MIT License. See LICENSE for more information.