ungleich-public
/
ungleich-staticcms
6
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

blog: update django hosting in k8s

This commit is contained in:
Nico Schottelius 2022-06-13 13:41:21 +02:00
parent f4b4560a5f
commit 1e18675220
1 changed files with 27 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
content/u/blog/2022-06-03-django-hosting-in-kubernetes/contents.lr
View File

@ -46,27 +46,41 @@ might potentially even come from a private registry.
All of our Django applications are using Postgresql for storing All of our Django applications are using Postgresql for storing
data. Postgresql is used by quite some other applications that we data. Postgresql is used by quite some other applications that we
deployed in k8s, so this is a no-brainer - Django hosting at ungleich deployed in k8s, so this is a no-brainer. Django hosting at ungleich,
even in k8s will be based on Postgresql. even in k8s, will be based on Postgresql.
Static data of Django applications can easily be stored on a PVC. This Static data of Django applications can easily be stored on a PVC. This
has the drawback that filesystem PVCs based on ceph block devices are has the drawback that filesystem PVCs based on ceph block devices are
RWO and thus in case of restart, there will be a short downtime. usually RWO and thus in case of restart, there will be a short downtime.
This is, generally speaking probably accepted, like a deploy would This is, generally speaking probably accepted, like a deploy would
have caused a short downtime on a VM as well. have caused a short downtime on a VM as well.
However alternatives would be a shared filesystem (such as However alternatives would be a shared filesystem (such as
NFS/CephFS), but they are usually slower than dedicated block NFS/CephFS), but they are usually slower than dedicated block
devices. devices - so reliability can be traded against speed. Maybe we offer
both options or add an NFS server as an option to our Django Hosting.
## Django startup ## Django startup / processes
On startup, Django will need to ensure the database schema On startup, Django will need to ensure the database schema
has been upgraded to the latest version. so something like `python has been upgraded to the latest version. so something like `python
manage.py migrate` should probably be called in an InitContainer for manage.py migrate` should probably be called in an InitContainer for
most apps. most apps. We could specify that the customer provided container
supports multiple commands:
- /init - anything that needs to be done *once* on startup
- /run - something that runs the actual site
Some django apps however utilise Celery
or [Django Q](https://django-q.readthedocs.io/en/latest/)
for async tasks. We don't know which system is used, but it would be easy to
add a flag to the hosting whether or not a third container
should be utilised. Thus we could define:
- If async container is defined, enable it and run /async (or similar)
## Secrets ## Secrets
@ -88,8 +102,8 @@ write for each client/customer.
This probably includes: This probably includes:
- Possible encrypted secrets - (Possible encrypted) Secrets
- Image definition - Image definitions
- Maybe even (part of) a pod definition? - Maybe even (part of) a pod definition?
Some parameters are likely to be stored in a different, ungleich only Some parameters are likely to be stored in a different, ungleich only
@ -98,3 +112,8 @@ writable repository, such as:
- Size of RAM - Size of RAM
- Number of CPUs - Number of CPUs
- Storage size (Postgresql, Static files, ...) - Storage size (Postgresql, Static files, ...)
## Status
This document is still WIP and will be used as a basis for
deploying our own Django apps first.