Our project is to develop a website management and hosting platform (based on the current Director platform) that is designed to scale. It is intended to replace the current Director platform which has problems with performance, scalability, and ease of use.
It is composed of three primary components:
orchestrator: The code that orchestrates the Docker containersmanager: The public-facing Django web application that provides an easy-to-use interface for managing websites.router: The code that runs on the balancers and handles a lot of the frontend for custom domains.
A full description of the project's architecture can be found in docs/ARCHITECTURE.md.
- Docker Engine: Used by the orchestrator to host sites that require dynamic generation
- Python 3.6+: Used by all components
- RabbitMQ: Used by the manager to broker messages for long-running tasks
- Celery: Used by the manager to manage long-running tasks
- Redis: Used by Django Channels on the manager as a channel layer
- PostgreSQL: Used by the manager as the relational database
- Nginx: Used by the manager, orchestrator, and router as a reverse proxy, a load balancer, and for serving static files
Each of the three components has specific Python dependencies described in each Pipfile.
We recommend that you have a server for each component to replicate an actual production environment.
The resources (storage, memory, CPU, and network) required to run Director 4.0 depend on the number of sites being run, user load, request count, and other factors.
We use Vagrant for providing a partial replica of a production environment. See docs/SETUP.md for details.
This code is released under the MIT License as described in LICENSE.
The authors of Director 4.0 would like to acknowledge the contributors to the TJHSST Director application for providing inspiration for this project.
The authors of Director 4.0 would also like to acknowledge the support of the TJHSST Computer Systems Lab, especially research advisor Dr. Patrick White for his guidance and mentoring.