-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the DjangoForge wiki!
- folder structure of the project
- what to touch (urls.py,settings.py)
- website
- logging app
- docker
- docker compose
- nginx
- github actions & secrets
- in production
- in development
the deploy consist in various steps. it is automated with github actions that require secrets to work. the actions are two:
- build and push
- deploy
the first action allow to create and image from the repository and upload it on the ghcr connected to the repo the second will need a digital ocean droplet to connect with, it will upload the docker-compose file and create and run the images.
the project is compose of three images: nginx, db and web.
- nginx is the container of nginx, it serves as a reverse proxy to direct connection to the web container
- web is container that run gunicorn/django is the actual app
- db is the container for postgres
only web is a personalized image. db and nginx are images that come from the dockerhub
the steps taken by the two actions are as follows:
- create two environment variables: REGISTRY and IMAGE_NAME REGISTRY point to the name of the registry: ghcr.io IMAGE_NAME point the name of the image it is used primarly to tag the image
- checkout the repo
- create the conf file ( more info in the next section )
- build the web image
- log in to the container registry
- tag image
- push image to the container registry
at this point you should be able to see the image in the section packages of you main GitHub page. it has the name equal to the environment variable IMAGE_NAME
- checkout the repo
- enter server and update & upgrade, install docker and docker compose
- enter server and create conf file
- enter server and scp docker-compose file and nginx conf
- enter server and stop old container, start new containers
the configuration file are basically two:
- one is a generic config file for both django and postgres
- the other is a nginx.conf file to set up nginx and SSL
Important Commands
To start:
sudo docker-compose -f docker-compose.yml up -d --build
sudo docker-compose -f docker-compose.yml exec web python manage.py migrate --noinput
sudo docker-compose -f docker-compose.yml exec web python manage.py collectstatic --no-input --clear
To stop:
sudo docker-compose down -v
-
Introduction: This Dockerfile defines a multi-stage build process for a production Django application. It creates an optimized and deployment-ready Docker image.
-
Builder Stage:
-
Base Image:
python:3.11.4-slim-buster
provides a minimal Python environment. -
Working Directory:
/usr/src/app
is set as the working directory. -
Environment Variables:
-
PYTHONDONTWRITEBYTECODE=1
: Disables bytecode generation for better performance. -
PYTHONUNBUFFERED=1
: Enables unbuffered output for real-time logging.
-
-
System Dependencies:
gcc
is installed for potential compiled dependencies. -
Pip Installation:
pip
is updated and used to install Python dependencies. - Copying Source Code: The entire project is copied to the builder's working directory.
-
Wheel Creation:
pip wheel
is used to create wheel files from dependencies in the build stage, improving efficiency in the final stage.
-
Base Image:
-
Final Stage:
-
Base Image: The
python:3.11.4-slim-buster
image is used again. -
App User: A dedicated user
app
is created to run the application. -
Application Directory: Directories are created for the
app
user, static files, media files, and the working directory is set. -
Copying Artifacts from Builder:
- Pre-built wheel files are copied from the build stage using
COPY --from=builder
. -
requirements.txt
is copied for reference.
- Pre-built wheel files are copied from the build stage using
-
Installing Dependencies:
pip install
is used to install dependencies using the pre-built wheel files andrequirements.txt
. - Copying Project: The entire project source code is copied to the application directory.
-
Permissions: Ownership of all files and directories is changed to
app:app
. -
Run User: The user is set to
app
to run the application. -
Command:
gunicorn
is run with specific options.
-
Base Image: The
-
Notes:
- This Dockerfile uses a multi-stage approach to improve efficiency and reduce the size of the final image.
- The
app
user is used for security purposes and to separate application privileges. - The
gunicorn
command is configured with specific options for worker management and timeout.
-
Usage: To use this Dockerfile:
- Build the image:
docker build -t my-django-app .
- Run the container:
docker run -p 8000:8000 my-django-app
(replace8000
with the desired port number)
- Build the image:
-
Further Resources:
- Docker documentation: https://docs.docker.com/
- Django documentation: https://docs.djangoproject.com/
- Gunicorn documentation: https://gunicorn.org/
-
Conclusion: This Dockerfile provides a robust and efficient way to build and deploy a Django application.
This script streamlines the deployment process, automating several manual steps, and can be triggered automatically on every push to the main branch of the GitHub repository.
-
Checkout Repository: Clones the repository GitHub into the GitHub Actions runner.
-
Define REPO_NAME: Extracts the repository name and saves it in the
REPO_NAME
variable within GitHub Actions Environment Variables ($GITHUB_ENV
). -
Configure Server:
Connects to the server configured in secret variables and performs setup tasks.
-
Clone Repository: Clones the GitHub repository inside the server using the GitHub username and repository name.
-
Activate Virtual Environment and install dependencies: Creates a Python virtual environment, activates it, and installs project dependencies.
-
Create .env file: Creates the
.env
file with necessary configurations. -
Run Django Commands: Executes Django commands for setup and configuration.
-
Configure Gunicorn: Configures Gunicorn for serving the Django application.
-
Configure Nginx: Configures Nginx as a reverse proxy.
-
Fix Firewall: Adjusts firewall rules to allow traffic.
-
Final Checks: Restarts services and performs checks to ensure successful deployment.
The website
module allows you to load images, gather them in galleries, add contacts, and opening hours. To use the module:
- Modify the landing page.
- Modify the navbar and footer with the links of all the pages you want to be accessible.
- Modify the view called "base", it will call the page
landing.html
. Add the info in the context you use in the landing. It will be the first page seen by the user. - Modify the favicon and title in the template
base.html
.
The website
application has a dashboard part that allows you to perform CRUD operations on graphical objects such as images and galleries...
The dashboard can be the place where all such operations for the other apps should be done.
It can be expanded by creating a dashboard directory inside the templates directory of the new app.
app folder
│ ├── ...
├── templates/
│ ├── dashboard
└── ...
This allows you to keep the dashboard components inside of the new app separated from the rest.
Inside this directory, there should be a file called dashboard.html
that expands using include dashboard.html
inside the website app.
This file should be expanded using the expand statement with templates that show the objects needed.