Update Readme
This commit is contained in:
parent
8d67c69dbc
commit
040932c0ee
1 changed files with 39 additions and 60 deletions
97
README.md
97
README.md
|
@ -17,16 +17,45 @@ Terminiert am ingress. Wie interagiert das mit taiga?
|
||||||
Eventuell wird dies hier relevant:
|
Eventuell wird dies hier relevant:
|
||||||
https://github.com/kaleidos-ventures/taiga-docker#session-cookies-in-django-admin
|
https://github.com/kaleidos-ventures/taiga-docker#session-cookies-in-django-admin
|
||||||
|
|
||||||
### Docker Compose -> Kubernetes
|
### Docker Compose (DC) -> Kubernetes
|
||||||
|
|
||||||
Wir müssen die compose-yamls nach kubernetes resources übersetzen.
|
We implemented a deployment and service in kubernetes for each DC Service.
|
||||||
|
Configmaps and secrets were implemented, to avoid redundancy and readability also to increase security a bit.
|
||||||
|
For all volumes described in DC we implemented PVCs and volume refs.
|
||||||
|
|
||||||
### Für das init deployment
|
A config.py (used for taiga-back ) was introduced for reference.
|
||||||
|
A config.json (used for taiga-front ) was introduced for reference.
|
||||||
|
NB: It might be necessary to actually map both from a config map to their respective locations in taiga-back and taiga-front. Description for that is [here](https://docs.taiga.io/setup-production.html).
|
||||||
|
A mix of both env-vars and config.py in one container is not possible.
|
||||||
|
|
||||||
|
#### depends_on
|
||||||
|
|
||||||
|
We currently assume, that it will work without explicitly defining a startup order.
|
||||||
|
|
||||||
|
#### DC Networking
|
||||||
|
|
||||||
|
https://github.com/compose-spec/compose-spec/blob/master/spec.md
|
||||||
|
|
||||||
|
The `hostname` KW sets the hostname of a container.
|
||||||
|
It should have no effect on the discoverability of the container in kubernetes.
|
||||||
|
|
||||||
|
The `networks` KW defines the networks that service containers are attached to, referencing entries under the top-level networks key.
|
||||||
|
This should be taken care of by our kubernetes installation.
|
||||||
|
|
||||||
|
#### Pod to Pod Possible Communications
|
||||||
|
|
||||||
|
Taiga containers that need to reach other taiga containers:
|
||||||
|
taiga-async -> taiga-async-rabbitmq
|
||||||
|
taiga-events -> taiga-events-rabbitmq
|
||||||
|
This is not quite clear, but probably solved with the implementation of services.
|
||||||
|
|
||||||
|
### Init container
|
||||||
|
|
||||||
Es gibt einen Init-Container mit namen *taiga-manage* im deployment.
|
Es gibt einen Init-Container mit namen *taiga-manage* im deployment.
|
||||||
ToDo: Dieser erstellt einen Admin User mit credentials aus dem taiga-back-secret.
|
Dieser erstellt einen Admin User mit credentials aus dem taiga-back-secret.
|
||||||
|
|
||||||
|
#### Einen admin-user anlegen
|
||||||
|
|
||||||
#### Einen admin-user anlegen:
|
|
||||||
https://github.com/kaleidos-ventures/taiga-docker#configure-an-admin-user
|
https://github.com/kaleidos-ventures/taiga-docker#configure-an-admin-user
|
||||||
|
|
||||||
folglich:
|
folglich:
|
||||||
|
@ -38,62 +67,12 @@ sollten für den Container gesetzt sein.
|
||||||
|
|
||||||
Dann noch ein run befehl mit: python manage.py createsuperuser im init container unterbringen.
|
Dann noch ein run befehl mit: python manage.py createsuperuser im init container unterbringen.
|
||||||
|
|
||||||
### deployment
|
### Deployments
|
||||||
|
|
||||||
Taiga reads many values in config.py from env vars as can be seen in the taiga-back [config.py](
|
Separate deployments exist for each of the taiga modules:
|
||||||
https://github.com/kaleidos-ventures/taiga-back/blob/main/docker/config.py). These are read from configmaps and secrets
|
|
||||||
in the deployment.
|
|
||||||
|
|
||||||
Mounting a configmap with a config.py as described here: https://docs.taiga.io/setup-production.html could be interesting. A mix of both env-vars and config.py in one container is not possible.
|
Taiga-back reads many values in config.py from env vars as can be seen in the taiga-back [config.py](
|
||||||
|
https://github.com/kaleidos-ventures/taiga-back/blob/main/docker/config.py). These are read from configmaps and secrets in the deployment.
|
||||||
An example for a config.py is given here:
|
|
||||||
https://github.com/kaleidos-ventures/taiga-back/blob/main/settings/config.py.prod.example
|
|
||||||
|
|
||||||
* taiga-db
|
|
||||||
* Postgres
|
|
||||||
* taiga-back
|
|
||||||
* taiga-async
|
|
||||||
* taiga-async-rabbitmq
|
|
||||||
* taiga-front
|
|
||||||
* taiga-events
|
|
||||||
* taiga-events-rabbitmq
|
|
||||||
* taiga-protected
|
|
||||||
* taiga-gateway
|
|
||||||
* Nginx???
|
|
||||||
* ersetzen durch metallb und ingresse
|
|
||||||
|
|
||||||
### Volume Mounts
|
|
||||||
|
|
||||||
* taiga-static-data:
|
|
||||||
* taiga-media-data:
|
|
||||||
* taiga-db-data:
|
|
||||||
* taiga-async-rabbitmq-data:
|
|
||||||
* taiga-events-rabbitmq-data:
|
|
||||||
|
|
||||||
### Secrets
|
|
||||||
|
|
||||||
* admin user?
|
|
||||||
* secret-key
|
|
||||||
* db
|
|
||||||
* email
|
|
||||||
* rabbit-mq
|
|
||||||
|
|
||||||
### Networking
|
|
||||||
https://github.com/compose-spec/compose-spec/blob/master/spec.md
|
|
||||||
|
|
||||||
|
|
||||||
The `hostname` KW sets the hostname of a container.
|
|
||||||
It should have no effect on the discoverability of the container in kubernetes.
|
|
||||||
|
|
||||||
The `networks` KW defines the networks that service containers are attached to, referencing entries under the top-level networks key.
|
|
||||||
This should be taken care of by our kubernetes installation.
|
|
||||||
|
|
||||||
Taiga containers that need to reach other taiga containers:
|
|
||||||
taiga-async -> taiga-async-rabbitmq
|
|
||||||
taiga-events -> taiga-events-rabbitmq
|
|
||||||
|
|
||||||
ToDo: How do we direct traffic towards the frontend pod?
|
|
||||||
Do we need to touch the frontend config regarding the default address (localhost:9000) of the API?
|
|
||||||
|
|
||||||
## Purpose
|
## Purpose
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue