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

View File

@ -46,27 +46,41 @@ might potentially even come from a private registry.
All of our Django applications are using Postgresql for storing
data. Postgresql is used by quite some other applications that we
deployed in k8s, so this is a no-brainer - Django hosting at ungleich
even in k8s will be based on Postgresql.
deployed in k8s, so this is a no-brainer. Django hosting at ungleich,
even in k8s, will be based on Postgresql.
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
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
have caused a short downtime on a VM as well.
However alternatives would be a shared filesystem (such as
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
has been upgraded to the latest version. so something like `python
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
@ -88,8 +102,8 @@ write for each client/customer.
This probably includes:
- Possible encrypted secrets
- Image definition
- (Possible encrypted) Secrets
- Image definitions
- Maybe even (part of) a pod definition?
Some parameters are likely to be stored in a different, ungleich only
@ -98,3 +112,8 @@ writable repository, such as:
- Size of RAM
- Number of CPUs
- 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.