Django Contained
Some notes on things that did not work along the tutorial…
Django app requires several modifications to run effectively inside of containers, like logging to standard output streams and configuring itself through environment variables passed into the container. In addition, offloading static assets like JavaScript and CSS stylesheets to object storage allows you to streamline and centralize the management of these files in a multi-container environment.
for some reason the Digital Ocean firewall got my local ip wrong..
Also, to get the migrations work I had to run the following :
GRANT ALL ON SCHEMA public TO username;
Making Django Configurable by Environment Variables
To apply this technique, open the polls-project/django-polls/mysite/settings.py file in your editor of choice, and move through it, externalizing the following variables with the provided default values:
- SECRET_KEY = os.getenv(‘DJANGO_SECRET_KEY’)
- DEBUG = os.getenv(‘DEBUG’, False)
- ALLOWED_HOSTS = os.getenv(‘DJANGO_ALLOWED_HOSTS’, ‘127.0.0.1’).split(‘,’)
Storage for static files
The django-storages package provides remote storage backends (including S3-compatible object storage) that Django can use to offload files. We’ll configure the Polls app to use django-storages to upload static files to a DigitalOcean Space, as outlined in Step 7 of How to Set Up a Scalable Django App with DigitalOcean Managed Databases and Spaces. In this guide, we’ll use DigitalOcean Spaces, but you can use any S3-compatible object storage provider.
From now on, when you run manage.py collectstatic to assemble your project’s static files, Django will upload these to remote object storage. Django is also now configured to serve static assets from this object storage service.
By default, Django logs information to standard output and standard error when running the development HTTP server or when the DEBUG option is set to True. However, when DEBUG is set to False or when using a different HTTP server, both of which are likely true in production environments, Django uses a different logging mechanism. Instead of logging everything of priority INFO and above to standard streams, it sends messages of priority ERROR or CRITICAL to an administrative email account.
This makes sense for many situations, but in Kubernetes and containerized environments, logging to standard output and standard error is highly recommended. Logging messages are collected in a centralized directory on the Node’s filesystem and are accessible interactively using kubectl and docker commands. This Node-level aggregation facilitates log collection by allowing operations teams to run a process on each node to watch and forward logs. To leverage this architecture, the application must write its logs to these standard sinks.
Fortunately, logging in Django uses the highly configurable logging module from the Python standard library, so we can define a dictionary to pass to logging.config.dictConfig to define our desired outputs and formatting. To learn more about this technique and others for configuring Django logging, consult https://lincolnloop.com/insights/django-logging-right-way/
Writing a django dockerfile:
https://www.caktusgroup.com/blog/2017/03/14/production-ready-dockerfile-your-python-django-app/
Configuring the environment vars
